# Activate a partner

`POST /lokta-lms/api/v1/sourcing-partners/{partnerId}/activation`

Activates a sourcing partner, so loans can be attributed to it.

Moves `pending` or `inactive` → `active`. Until this happens the partner **cannot be attributed a loan**, which is what makes this the step that closes onboarding rather than a cosmetic flag.

Refused with `422 sourcing/partner_has_no_active_terms` unless an agreement is in force. An active partner can be attributed loans, and activating one with no terms would leave the lender owing fees on no agreed basis; a gap that otherwise surfaces at the first fee run rather than while somebody could still fix it.

`reason` is optional here: activation is the expected end of onboarding and explains itself. It is recorded in `status_history` either way.

`onboarded_on` is stamped the first time a partner becomes active and never overwritten; a partner reactivated in 2028 was still onboarded when it first went live.

## When to use it

This is the last step of onboarding. Call it once terms are in place.

## Worth knowing
- Refused with 422 sourcing/partner_has_no_active_terms when no agreement is in force.

## Parameters
- `partnerId` (path, string, required): Opaque partner id, spr_…
- `Idempotency-Key` (header, string): Per-intent key

## Request body (application/json)
- `reason` (string): Optional here. Activation is the expected end of onboarding.

## Responses
- `default`: default response

## Example request (cURL)
```bash
curl -X POST \
  'https://default.lokta.tech/lokta-lms/api/v1/sourcing-partners/{partnerId}/activation' \
  -u '{username}:{password}' \
  -H 'Tenant-Identifier: default' \
  -H 'Content-Type: application/json' \
  -d '{
  "reason": "string"
}'
```

Interactive: https://developer.lokta.ai/reference#operation/activate