---
title: "Understanding Authentication"
slug: "understanding-authentication-1"
updated: 2026-05-04T10:11:15Z
published: 2026-05-19T17:05:10Z
canonical: "help.idibilling.com/understanding-authentication-1"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.idibilling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding Authentication

In order to develop to IDI’s web services, a developer must be able to properly authenticate. The goal of this post is to explain what is involved in understanding this crucial requirement.

#### IP ORIGINATION

IDI’s web services are protected by IP origination. If you are unable to load [https://api.idibilling.com](https://api.idibilling.com/) from a browser, your client IP is blocked. Contact your IDI Billing representative to have the required IP’s added.

#### WEB SERVICE REQUESTS

Each request to an IDI web services requires proper authentication. Depending on the endpoint the authentication may be different.

- The SOAP-based endpoints require a SAML token from IDI’s Security Token Service AND the request must be signed using [XML DSig](https://en.wikipedia.org/wiki/XML_Signature)
- REST-based endpoints use a Simple Web Token (SWT)

For both of these methods, a proper username and password is required. For web service authentication, a specific user type is required. Contact your IDI Billing representative if you need this username or password. The user is usually in the format: XYZ_ws_user.

#### OBTAINING A SAML TOKEN

The SAML token is requested via the [Security Token Service](https://support.idibilling.com/webapi/Security%20Token%20Service%20API%20Documentation/) Issue method. The request should look similar to the below XML with the following values replaced:

- {USERNAME} – replace with the web service user
- {PASSWORD} – replace with the password for the specified web service user
- {STS_URL} – URL of the Security Token Service, like https://api.idibilling.com/SecurityToken/1X/xyz01_T_TEST
- {APPLIES_TO} – this is most likely to be the string: http://idibilling.com/webservices

```plaintext
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ns2="http://www.w3.org/2005/08/addressing">
<env:Header>
    <ns2:Action env:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</ns2:Action>
    <ns2:To env:mustUnderstand="1">{STS_URL}</ns2:To>
    <o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
    <o:UsernameToken>
        <o:Username>{USERNAME}</o:Username>
        <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{PASSWORD}</o:Password>
    </o:UsernameToken>
</o:Security>
</env:Header>
<env:Body>
    <trust:RequestSecurityToken xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <ns2:EndpointReference>
        <ns2:Address>{APPLIES_TO}</ns2:Address>
    </ns2:EndpointReference>
</wsp:AppliesTo>
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
</trust:RequestSecurityToken>
</env:Body>
</env:Envelope>
```

A valid response would return a SAML token that can be used for subsequent calls.