LENDING / ACCESS
Authentication
All calls to the AC Lending API are authenticated. Each client is issued its own client ID and API key.
Required headers
| Header | Example | Usage |
|---|---|---|
X-AC-Client-ID |
YOUR_CLIENT_ID |
Identifies the calling AC client |
x-api-key |
YOUR_API_KEY |
Unique API credential for that client |
Content-Type |
application/xml |
Required on application submission |
POST /post HTTP/1.1
Host: api.authorisedcompliance.com
X-AC-Client-ID: YOUR_CLIENT_ID
x-api-key: YOUR_API_KEY
Content-Type: application/xml
For results polling, retain the two authentication headers and use the URL returned by AC.
Credential handling
- Keep credentials on a backend server or approved secret store, never in browser JavaScript, mobile bundles, public repositories or support screenshots.
- Use HTTPS for all production requests.
- Never reuse a credential between clients or production and staging.
- AC can disable a credential or restrict permitted IP addresses under the agreed onboarding configuration.
- Rotate suspected compromised keys and notify AC via your established support contact.
Authentication failures
An invalid or disabled client, missing credentials, or an API key that does not match the Client ID must be rejected before any downstream submission. These failures normally produce a 401 or 403 response, depending on the gateway layer.
Route access
A different URL is not a security boundary by itself. Client-to-route access is controlled by AC's authorization configuration. Do not assume another client's route is available just because it shares the same domain.