Updates

GET /me/updates returns everything that happened to the person's bookings, payments, payouts and conversations, and to the action links your application created, oldest first. Each item is one change, whoever made it: the person, the other party, your application, another application or DJfindr.

Poll the feed and store the cursor it returns, or register a webhook and use the feed to recover anything a delivery missed.

Request

GET /prod/v1/me/updates?since=eyJ2IjoxLCJzIjoxMDQyfQ&limit=50&types=booking.*,payment.paid HTTP/1.1
Host: api.djfindr.com
Authorization: Bearer djf_at_...

The endpoint requires one of bookings:read, payments:read, inbox:read or account:read. Each item also requires the read scope of its own family; items the token cannot read are omitted, not reported as errors. An API key returns 403 with code: "oauth_required".

Response

The feed uses the list envelope with two differences:

{
  "success": true, "error": "", "code": "", "fields": {},
  "count": 1, "remaining": 0, "cursor": "eyJ2IjoxLCJzIjoxMDQyfQ",
  "data": [
    {
      "id": "aev_01K7...", "seq": 1042, "type": "booking.offer_sent",
      "created_at": "2026-10-19T17:02:11.204Z", "role": "client",
      "subject": { "type": "proposal", "id": "prop_..." },
      "proposal_id": "prop_...", "payment_id": null, "conversation_id": null,
      "data": { "proposal_id": "prop_...", "event_id": "evt_...", "from": "pending_offer", "to": "offer_sent", "updated_at": "2026-10-19T17:02:11.200Z" }
    }
  ]
}

Polling

1. Store cursor after every response, including an empty one. At the end of the feed the cursor still advances.
2. While remaining is greater than 0, request the next page immediately.
3. Once remaining is 0, poll every 30 to 60 seconds.
4. Read the record for details, for example GET /me/bookings/proposals/{id} or GET /me/conversations/{id}/messages?after=.

🚧

Event retention

Events are kept for 30 days. A cursor that was not used while the events after it were deleted returns 409 with code: "cursor_expired". Start again from a timestamp.

Event types

A card dispute on a payment can change the DJ's payout for it: a payout not yet sent is reduced (payout.updated) or canceled (payout.canceled), and a sent one is reversed (payout.reversed). A payout sent for less than it was scheduled at, because the payment was partly refunded first, produces a single payout.paid with the amount sent, not a payout.updated before it.

Rarely, DJfindr support takes over a payment's payout and settles it by hand, for example when a card dispute that had taken money from the payout is won, or a refund fails after it had gone through. A payout not yet sent is then canceled (payout.canceled), its failure_reason says that DJfindr support is handling it, and it is never sent on its own afterwards. While support handles it, the payout reads on_hold: true in GET /me/transfers and GET /me/transfers/{id} (and in a received payment's transfer), whether it was sent or not, and the payout summary counts it only in on_hold_amount and on_hold_count, never as scheduled, paid out or reversed; read on_hold rather than the words of failure_reason. Once DJfindr support records what it did, the payout reads on_hold: false, leaves on_hold_amount and on_hold_count, and reads as what the DJ received; the payout summary then counts it by that reading. completed (the amount sent, by the payout and by hand) counts in paid_out_amount net of any reversal, and the reversal in reversed_amount. reversed (all of the money sent was taken back) counts in reversed_amount only, with nothing paid out. canceled with closed_by_support: true means DJfindr support closed the payout with nothing sent: show it as closed, never as reversed or returned, and read closed_by_support rather than the words of failure_reason; it counts in no figure, so never add its amount to a paid-out total. closed_by_support is on every payout (and on a received payment's transfer), false on every other payout, one support sent by hand included, which reads as an ordinary completed payout. Once money was recorded as sent, a paid payment reads transferred in GET /me/payments/received and GET /me/payments/received/{id} and in a PayLink's payment_status, as for a payout DJfindr sent; the payer's own view of the payment keeps paid. No payout.* or payment.* event follows that record (no payment.transferred either), nor a later reversal of money support sent by hand, though either changes the payout's figures. A payout.* event carries the payout as it is stored, without the money support sent by hand, so once support has recorded a payout an event's amount, amount_reversed and status can differ from GET /me/transfers/{id}. An app that keeps payouts or payments from events polls a payout that reads on_hold: true until it reads on_hold: false, then reads its payment again, and from then on takes that payout's figures from GET /me/transfers/{id}, never from events. A payout that turns out to have been sent already becomes completed (payout.paid), even after its payout.canceled. A reversal of the payout DJfindr sent itself still produces payout.reversed, with the stored figures; a reversal of money support sent by hand produces no event.

New event types are added over time. Ignore types your application does not recognize.

A completed checkout, for example, produces booking.document_completed, booking.awaiting_payment, payment.created, payment.paid, booking.confirmed and link.completed, followed on a deposit booking by payment.created for the balance.