Connect a partner to Matterlegal

A reference workflow using the real application APIs. Stripe remains test-only. This guide does not certify an external partner or authorize legal action.

  1. A partner administrator creates a partner organization, registers an application in Developer console, and sets exact HTTPS origins and callback/logout URLs. Enable SSO and wait for provisioning to become active.
  2. Create an application-bound credential with only intake:create and, if needed, status:read. Keep it on the partner backend, never in HTML, local storage or the embedded SDK.
  3. Use the working embedded SDK reference for public application ID and PKCE sign-in. The individual must approve the exact application consent. An API key is never a substitute for that identity.
  4. From your backend call POST /api/v1/intakes using the scoped key, a fresh Idempotency-Key, and the intended independent client's own sign-in email. Only non-confidential routing details belong in the referral summary. Include practiceArea when known: housing, employment, family, consumer, commercial, criminal or other; omit it or use unspecified when unsure. The Maharashtra housing checklist is enabled only for explicitly classified housing matters in Maharashtra.
  5. The client signs in with that email, accepts the matter invitation, confirms their account and objectives, uploads originals privately, nominates counsel and separately accepts the exact engagement terms. The lawyer records actual conflict screening and independently accepts. Pilot consent is a different step.
  6. A law office may coordinate assignments after engagement; office administrators do not thereby receive client evidence. Supporting users need their own explicit case/file grants.
  7. The client explicitly enables status disclosure. Follow every nextCursor from GET /api/v1/matters?paged=1. Only the same application's consented status is returned; no private accounts, evidence, legal arguments or settlement terms.
  8. Subscribe an owned HTTPS webhook endpoint. Verify HMAC_SHA256(secret, timestamp + "." + rawBody), reject timestamps over 300 seconds old, use constant-time comparison and deduplicate delivery IDs. Inspect actual HTTP delivery receipts in Developer console.
  9. Test revoking client disclosure, credential, subscription, application and individual grants. Future status delivery must stop. Previously delivered data cannot be remotely erased. Test another client's/app's IDs and cursor: access must be denied.
  10. Use Integration readiness for observed configuration/receipts. Complete the actual partner browser and operator acceptance separately; an observed provisioning record is not a passed external integration.

Backend request

POST https://lawyer.diy/api/v1/intakes
Authorization: Bearer <server-side application credential>
Content-Type: application/json
Idempotency-Key: <unique UUID>

{"title":"Client-approved routing title","clientEmail":"owned-client@example.org","city":"Mumbai","state":"Maharashtra","practiceArea":"housing","language":"Marathi","summary":"Non-confidential routing only"}

Use only owned test mailboxes during validation. The sample address is illustrative; reserved test-domain invitations do not prove email delivery. Replaying the same request with the same key must return the same intake. No live payment, filing, service or signature occurs in this flow.

Open Developer console · Privacy · Terms