Creator onboarding

POST /v1/creators

Intended contract

{
  "person": {
    "first_name": "…",
    "last_name": "…",
    "email": "…",
    "document": { "type": "CC", "number": "…" }
  },
  "organization": {
    "legal_name": "Fundación Ejemplo",
    "tax_id": "…",
    "country": "CO"
  },
  "redirect_url": "https://example.org/onboarding/done"
}

202 Accepted:

{
  "id": "crt_01J9Z4M2K7QF3B",
  "object": "creator",
  "status": "awaiting_verification",
  "verification_url": "https://…",
  "created_at": "2026-08-17T14:00:00Z"
}

Send the person to verification_url to complete identity verification; the decision resolves by webhook, and they land back on your redirect_url.

Why you want this, and what to do until then

Today POST /v1/vakis requires owner.email to resolve to an existing Vaki account, and returns 422 owner_not_found if it does not. That means a partner onboarding a new organisation has to get someone to sign up on vaki.co first — a hand-off out of your product and back, which is exactly where funnels die.

This endpoint removes that step: you create the creator, they verify once, and the causes you create for them work immediately.

Until it ships: have the organisation’s representative create a Vaki account before you call POST /v1/vakis, and handle 422 owner_not_found as a “finish signing up” state in your own UI rather than as an error toast.

What is actually being built

Identity verification already runs inside Vaki, but scoped to payments rather than to people who own causes. Generalising it, plus adding the organisation-level background check that compliance requires for a Colombian non-profit entity, is the work. The published contract is stable enough to design against; the shape of organization may grow fields as compliance specifies them.