BiPRO Integration

Receive policy documents from Liechtenstein Life in your broker management system using the BiPRO Norm 430 SOAP interface. Documents are pushed as shipments that you fetch, read, and acknowledge.

Credentials​

Your Client ID and Client Secret are displayed in Partner Life under Profile → BiPRO Integration. The secret is shown once when the integration is created — store it securely. You can rotate it at any time from the same page.

Environments​

Use the test environment for all initial integration work. Production credentials are separate and must be obtained after test verification.

Endpoints​

Authentication​

Authentication uses the OAuth 2.0 client credentials flow. Request a token before each SOAP session — tokens are valid for 15 minutes.

1. Obtain a token​

curl -X POST https://api.life.li/bipro/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=bipro:transfer"

Response:

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "bipro:transfer"
}

2. Call the SOAP endpoint​

Pass the token in the Authorization header on every SOAP request:

Authorization: Bearer YOUR_ACCESS_TOKEN

BiPRO STS (Norm 260/410) — Username/Password​

If your platform speaks WS-Trust rather than OAuth 2.0, request tokens through the BiPRO Norm 260/410 SecurityTokenService instead. Both paths issue the same underlying token and share one rate limit — use whichever fits your SOAP stack.

Use the same Client ID and Client Secret as the OAuth flow: Client ID as the WS-Security username, Client Secret as the password. Credentials are per broker — each broker platform stores each broker's own Client ID and Secret from Partner Life, not a single shared account.

The WSDL is published at:

GET https://api.life.li/bipro/norm410/2.7?wsdl

1. Request a token​

Send a WS-Trust RequestSecurityToken with a WS-Security UsernameToken:

curl -X POST https://api.life.li/bipro/norm410/2.7 \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:UsernameToken>
        <wsse:Username>YOUR_CLIENT_ID</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">YOUR_CLIENT_SECRET</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </S:Header>
  <S:Body>
    <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
    </wst:RequestSecurityToken>
  </S:Body>
</S:Envelope>'

TokenType and RequestType must match exactly as shown — any other value returns a SOAP fault.

2. Read the response​

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <wst:RequestedSecurityToken>
        <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
          <wsc:Identifier>bipro:eyJ...</wsc:Identifier>
        </wsc:SecurityContextToken>
      </wst:RequestedSecurityToken>
      <wst:Lifetime xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsu:Created>2026-07-06T12:00:00Z</wsu:Created>
        <wsu:Expires>2026-07-06T12:15:00Z</wsu:Expires>
      </wst:Lifetime>
    </wst:RequestSecurityTokenResponse>
  </soap:Body>
</soap:Envelope>

The <wsc:Identifier> is bipro:-prefixed and valid for 15 minutes, matching <wsu:Created>/<wsu:Expires>. Store the full identifier, prefix included — you'll need it as-is for the SOAP header below.

3. Call Norm 430 with the token​

Present the identifier as a SecurityContextToken in the SOAP header:

<soap:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
      <wsc:Identifier>bipro:eyJ...</wsc:Identifier>
    </wsc:SecurityContextToken>
  </wsse:Security>
</soap:Header>

The HTTP Authorization: Bearer YOUR_ACCESS_TOKEN header from the OAuth flow above still works too — the bipro: prefix is optional there, the server strips it automatically if present.

Faults​

Errors come back as a SOAP fault with a nachr:BiproException detail carrying a MeldungID. Authentication failures — unknown Client ID, wrong secret, or a disabled integration — all return the same fault (MeldungID 00960), so a failed request never reveals which part of the credential pair was wrong. This fault shape is specific to this STS endpoint — Norm 430 authentication failures return the transfer service's own fault format.

SOAP Operations​

All operations are sent as POST requests to /bipro/norm430/2.7 with Content-Type: text/xml.

listShipments​

Lists available (unacknowledged) shipments for your integration.

curl -X POST https://api.life.li/bipro/norm430/2.7 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:tran="http://www.bipro.net/namespace/transfer"
  xmlns:nachr="http://www.bipro.net/namespace/nachrichten">
  <soap:Body>
    <tran:listShipments>
      <tran:Request>
        <nachr:BiPROVersion>2.7.0.1.0</nachr:BiPROVersion>
        <tran:BestaetigeLieferungen>false</tran:BestaetigeLieferungen>
      </tran:Request>
    </tran:listShipments>
  </soap:Body>
</soap:Envelope>'

The response contains a <tran:Lieferung> element for each available shipment, each with an <tran:ID> you use for getShipment and acknowledgeShipment.

getShipment​

Fetches the full shipment payload, including the document encoded as base64 in <allg:Daten>.

curl -X POST https://api.life.li/bipro/norm430/2.7 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:tran="http://www.bipro.net/namespace/transfer"
  xmlns:nachr="http://www.bipro.net/namespace/nachrichten">
  <soap:Body>
    <tran:getShipment>
      <tran:Request>
        <nachr:BiPROVersion>2.7.0.1.0</nachr:BiPROVersion>
        <tran:ID>SHIPMENT_ID</tran:ID>
      </tran:Request>
    </tran:getShipment>
  </soap:Body>
</soap:Envelope>'

Decode the document from the response:

# Extract and decode the base64 document from <allg:Daten>
echo "BASE64_CONTENT" | base64 -d > document.pdf

Key fields in the response:

acknowledgeShipment​

Confirm receipt of a shipment. Call this after successfully processing the document. Acknowledged shipments no longer appear in listShipments.

curl -X POST https://api.life.li/bipro/norm430/2.7 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:tran="http://www.bipro.net/namespace/transfer"
  xmlns:nachr="http://www.bipro.net/namespace/nachrichten">
  <soap:Body>
    <tran:acknowledgeShipment>
      <tran:Request>
        <nachr:BiPROVersion>2.7.0.1.0</nachr:BiPROVersion>
        <tran:ID>SHIPMENT_ID</tran:ID>
      </tran:Request>
    </tran:acknowledgeShipment>
  </soap:Body>
</soap:Envelope>'

A successful response includes <StatusID>OK</StatusID>.

Recommended polling flow​

1. listShipments — identify new shipment IDs
2. getShipment — download and process each document
3. acknowledgeShipment — confirm receipt

Repeat on a schedule (e.g. every few minutes). Only unacknowledged shipments appear in listShipments.

Security best practices​

• Store your Client Secret in a secrets manager — never in source code or config files
• Request tokens server-side only — never expose credentials to client-side code
• Rotate your Client Secret periodically from the Partner Life portal
• Use HTTPS for all requests (enforced — plain HTTP is rejected)