BridgeCredit subjects
- POST
/credit-scoring/subject/linkLink this tenant's user to a credit subject - DELETE
/credit-scoring/subject/link/{userReference}End this tenant's link - GET
/credit-scoring/subject/link/{userReference}Read this tenant's link for one of its users
POST Link this tenant's user to a credit subject
POST /credit-scoring/subject/link
Establishes that a user in this tenant is a particular person, on the evidence of an identification this tenant has already had verified. If that person is already known to the platform the existing subject is joined; if not, one is created. The response is identical either way, because a caller able to tell them apart would learn whether a given person is known elsewhere on the platform.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Content-Type | application/json |
Example
Request body: CreditSubjectLinkRequest · Response: CreditSubjectLinkResponse
curl -X POST "https://api.bridgemoni.com/credit-scoring/subject/link" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" \
-H "Content-Type: application/json" \
-d '{
"userReference": "text",
"identificationReference": "text"
}'{
"userReference": "text",
"identificationReference": "text"
}{
"data": {
"reference": "text",
"subjectReference": "text",
"userReference": "text",
"identificationReference": "text",
"levelOfAssurance": 1,
"linkedAt": "2027-03-14T14:30:01"
},
"description": "Link this tenant's user to a credit subject"
}Responses
| Status | When |
|---|---|
200 | Linked |
400 | The identification belongs to a different user, or is not an accepted type |
409 | Not verified, assurance below the floor, or this user is already linked |
DELETE End this tenant's link
DELETE /credit-scoring/subject/link/{userReference}
The tenant stops contributing this user's behaviour and stops being able to read the subject. The subject and its history are untouched: a tenant walking away does not erase a person, and the fact that this tenant once held a link stays part of the subject's own disclosure history.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
userReference |
Example
Response: Void
curl -X DELETE "https://api.bridgemoni.com/credit-scoring/subject/link/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV"{
"description": "End this tenant's link"
}Responses
| Status | When |
|---|---|
200 | Unlinked |
GET Read this tenant's link for one of its users
GET /credit-scoring/subject/link/{userReference}
404 when this tenant holds no live link - deliberately the same answer as for a user that does not exist. 503 while the subject is being merged, because a half-merged file would otherwise be described as though it were settled.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
userReference |
Example
Response: CreditSubjectLinkResponse
curl -X GET "https://api.bridgemoni.com/credit-scoring/subject/link/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV"{
"data": {
"reference": "text",
"subjectReference": "text",
"userReference": "text",
"identificationReference": "text",
"levelOfAssurance": 1,
"linkedAt": "2027-03-14T14:30:01"
},
"description": "Read this tenant's link for one of its users"
}Responses
| Status | When |
|---|---|
200 | Link returned |
404 | No live link for that user |
503 | The subject is mid-merge. Retry |
Generated from the OpenAPI document. Branch on the HTTP status: there is no machine-readable error code on the wire. Errors