> Dating app API for developers | Dating API: https://www.datingapi.io/developers

Product / Developers

# An API that already knows what a match is.

Members, photos, decks, likes, matches, messages, reports, ID checks and billing, as plain REST endpoints. Your developers build the screens that make you different. We run the rest.

[Request sandbox keys](https://www.datingapi.io/contact) [Read the reference](#reference)

Base URL: platform.datingapi.io/v1

\# A member likes someone. The reply says if it's a match.
curl -X PUT https://platform.datingapi.io/v1/me/likes/mbr\_8f2k1 \\
  -H "Authorization: Bearer $MEMBER\_TOKEN" \\
  -d '{"liked": true}'

{
  "liked": true,
  "matched": true,
  "member": { "id": "mbr\_8f2k1", "name": "Maya", "age": 29,
              "identity\_verified": true, "network": false }
}

What’s in the API

## Built for the screens dating apps actually have.

Every endpoint maps to something a member does. No generic “objects” to model your way around.

| Area | Endpoints | Notes |
| --- | --- | --- |
| **Accounts** | register · sign in · POST /v1/session/refresh · DELETE /v1/me | Member tokens you can refresh. Sign-up comes from the member’s own device. |
| **Profile and photos** | GET /v1/me · PATCH /v1/me/profile · POST /v1/me/photos | Fields defined per app in the console |
| **Discovery** | POST /v1/me/search · POST /v1/me/search/deck · GET /v1/me/members/{id} | 25 a page, with has\_more |
| **Likes and matches** | PUT /v1/me/likes/{id} · GET /v1/me/likes/received · POST /v1/me/reactions/{id} | "matched": true in the reply |
| **Messages** | GET /v1/me/messages · POST /v1/me/messages/{id}/replies | Photos, unread counts, priority messages |
| **Safety** | POST /v1/me/blocks/{id} · POST /v1/me/reports | Reports go straight to the review team |
| **ID checks** | POST /v1/me/identity-verifications · GET /v1/me/identity-verification | Badge shows across your app |
| **Questions** | GET /v1/me/questions/next · GET /v1/me/members/{id}/answer-stats | “You agree on 7 of 9” |
| **Billing** | POST /v1/sites/{site}/members/{member}/transactions | Report store sales from your server. No commission. |
| **Views and reactions** | GET /v1/me/views/received · POST /v1/me/reactions/{id} | Who viewed you, and reactions to photos |
| **Similar members** | GET /v1/me/members/{id}/similar | “More like this” on any profile |
| **Introductions** | POST /v1/me/introductions · GET /v1/me/introductions/quota | One message to up to 100 people, with a daily allowance |
| **Boosts** | POST /v1/me/boosts | Spend a boost from the member’s balance |
| **Checkout and plans** | GET /v1/prices · POST /v1/me/checkouts · GET /v1/me/subscription | Sell plans on the web, then cancel or restore them |
| **Email links** | POST /v1/sessions/exchange · POST /v1/password-resets | Sign-in, confirmation, password reset and one-click unsubscribe |
| **Messages from your team** | GET /v1/me/messages/site | Your own announcements in each member’s inbox |

Paths shown for orientation. The API reference, with exact parameters, headers and responses, is shared with partners during onboarding.

How it behaves

## Predictable, on purpose.

Idempotency-Key

### Safe retries

Writes can carry an idempotency key, so a retried request only ever happens once. Nobody gets a message twice.

network: true

### Network members, marked

Set private, backfill or shared in the console. The same endpoints return network members, marked network: true, and nothing else about where they joined.

pool\_limit\_reached

### Errors you can act on

Every error has a stable code and a plain message, so your app can show the right thing instead of a spinner.

429 + Retry-After

### Generous limits

Rate limits set for your volume, with a clear Retry-After when you hit one.

GET /v1/site

### Driven by your settings

Your app reads its own fields, report reasons and rules from the API, so the console changes the app without a release.

webhooks

### Webhooks

Your server hears about matches, messages, likes, ID results, removals and payments as they happen, ready for push notifications. Coming soon.

Webhooks

## Know the moment something happens.

Coming soon. Every event will arrive as the same small envelope: an id, the event type, your site and the time. Member ids match the ones the API gives your app.

-   **Members** Sign-ups, approvals, removals and deletions
-   **Photos and ID checks** Approved or turned down, with the reason
-   **Likes, matches and messages** Ready to send as push notifications
-   **Views and reactions** Who looked, and who reacted
-   **Payments** Payments taken, plans cancelled or restored
-   **Your own messages** Announcements from your team to members

The full event list comes with the API reference, shared on request.

Resources

## Everything your team needs, sent when you ask.

[**API reference** Every endpoint, with examples. Shared on request](https://www.datingapi.io/contact) [**Partner guides** Six guides, from setup to billing. Shared on request](https://www.datingapi.io/contact) [**Sandbox keys** A test app with test members. Ask and we’ll set it up](https://www.datingapi.io/contact) [**Status** Live and past incidents](https://www.datingapi.io/security#status)

Changelog

## Recent changes.

Oct 2026 Priority messages

Pin a message to the top of the recipient’s inbox. Unread after seven days, the credit goes back.

Sep 2026 Introductions

One message to up to 100 people, with candidates that exclude anyone already contacted.

Aug 2026 Answer stats

“You agree on 7 of 9” between any two members who have answered shared questions.

Jul 2026 Hosted web checkout

Card checkout for web apps, with you or us as merchant of record. You draw the paywall.