Legacy API migration guide

Use case: creating an appointment type. Replace this request with POST /v1/appointment-types.

Use case: listing appointments for one contact. Replace this request with GET /v1/appointments?contact=<contact_id>.

Use case: listing appointments for one contact. Replace this request with GET /v1/appointments?contact=<contact_id>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: reading one appointment by external id. Because appointment external ids are unique, replace this request with GET /v1/appointments/by?external_id=<external_id>.

Use case: listing appointments after a start time. Replace this request with GET /v1/appointments?start_time[gt]=<timestamp>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing appointments with detail fields. Replace this request with GET /v1/appointments?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: creating an appointment with detail fields. Replace this request with POST /v1/appointments and send those fields on the appointment body.

Use case: updating an appointment with detail fields. Replace id-based updates with PATCH /v1/appointments/{id}; replace external-id based updates with PATCH /v1/appointments/by?external_id=<external_id>.

Use case: deleting one appointment by external id. Replace this request with DELETE /v1/appointments/by?external_id=<external_id>.

Use case: deleting one appointment by external id. Replace this request with DELETE /v1/appointments/by?external_id=<external_id>.

Use case: listing contact lists. Replace this request with GET /v1/contact-lists.

Use case: finding contact lists changed since a timestamp. Replace this request with GET /v1/contact-lists?updated_at[gte]=<timestamp>; the new API exposes the contact-list update timestamp for this sync-style list filter.

Use case: finding contact lists by name. Replace this request with GET /v1/contact-lists?name=<name>.

Use case: finding contact lists by name. Replace this request with GET /v1/contact-lists?name=<name>.

Use case: listing contact-list contacts. Replace this request with GET /v1/contact-lists/{id}/contacts; use page_token for additional pages instead of offset when paginating.

Use case: listing contacts in one contact list. Replace this request with GET /v1/contact-lists/{id}/contacts; use page_token for additional pages instead of offset when paginating.

Use case: creating a contact list. Replace this request with POST /v1/contact-lists.

Use case: adding one contact to a contact list. Replace this request with POST /v1/contact-lists/{id}/contacts/{contact_id}.

Use case: clearing all contacts from one contact list. Replace id-based requests with POST /v1/contact-lists/{id}/contacts/clear; replace external-id based requests with POST /v1/contact-lists/by/contacts/clear?external_id=<external_id>.

Use case: deleting one contact list by id. Replace this request with DELETE /v1/contact-lists/{id}.

Use case: removing contacts from a contact list in bulk. When the integration can reset the whole list, replace this request with POST /v1/contact-lists/{id}/contacts/clear before rebuilding the membership.

Use case: listing contacts. Replace this request with GET /v1/contacts.

Use case: listing contacts created since a timestamp. Replace this request with GET /v1/contacts?limit=<limit>, follow page_token through every page, and apply the created_at boundary client-side. The new API does not currently expose a created_at list filter.

Use case: reading one contact by email. Replace this request with GET /v1/contacts/by?email_address=<value>.

Use case: listing contacts that have an email address. Replace this request with GET /v1/contacts and check the returned contact identities client-side.

Use case: reading one contact by external_id. Replace this request with GET /v1/contacts/by?external_id=<value>.

Use case: reading one contact by external_id. Replace this request with GET /v1/contacts/by?external_id=<value>.

Use case: reading one contact by external_id. Replace this request with GET /v1/contacts/by?external_id=<value>.

Use case: reading one contact by external_id. Replace this request with GET /v1/contacts/by?external_id=<value>.

Use case: listing contacts by external ids. Replace this request with GET /v1/contacts?external_id[in]=<external_ids>.

Use case: listing contacts without an external id. Replace this request with GET /v1/contacts?external_id[is_null]=true.

Use case: finding a contact by external id pattern. If the pattern is actually a complete external id, replace this request with GET /v1/contacts/by?external_id=<external_id>. The new API does not support partial external_id matching yet; if your integration depends on partial matching, reach out to us with the concrete use case.

Use case: syncing contacts with external ids that were updated after a timestamp. This history-style sync use case will be covered by the upcoming audit log endpoint rather than by a new API contact list filter.

Use case: searching contacts. Use the List Contacts search parameter for normalized literal substring matching across contact identity fields, or use direct filters such as email, phone number, or external_id.

Use case: reading one contact by id. Replace this request with GET /v1/contacts/{id}.

Use case: listing contacts by id. Replace this request with GET /v1/contacts?id[in]=<contact_ids>&include=identities. Read WhatsApp handles from included identities instead of the legacy top-level whatsapp field.

Use case: finding contacts created after a timestamp or changed by an import. This history-style import/change lookup will be covered by the upcoming audit log endpoint rather than by a contact list filter; use page_token rather than offset when migrating adjacent list pagination.

Use case: finding contacts by any of several email addresses. Send one GET /v1/contacts/by?email_address=<email> request per value, then merge and deduplicate the returned contacts client-side.

Use case: finding contacts by any of several phone-number locators. Replace the OR request with one GET /v1/contacts/by?sms_phone_number=<sms> request per SMS value and one GET /v1/contacts/by?whatsapp_phone_number=<whatsapp> request per WhatsApp value, then merge and deduplicate the returned contacts client-side.

Use case: reading one contact by sms. Replace this request with GET /v1/contacts/by?sms_phone_number=<value>.

Use case: syncing contacts updated after a timestamp. This history-style sync use case will be covered by the upcoming audit log endpoint rather than by a contact list filter.

Use case: syncing contacts updated since a timestamp. This history-style sync use case will be covered by the upcoming audit log endpoint rather than by a contact list filter.

Use case: reading one contact by whatsapp. Replace this request with GET /v1/contacts/by?whatsapp_phone_number=<value>.

Use case: reading one contact by whatsapp. Replace this request with GET /v1/contacts/by?whatsapp_phone_number=<value>.

Use case: reading a contact and its conversations by external id. Replace this request with GET /v1/contacts/by?external_id=<external_id> for the contact and GET /v1/conversations?contact_external_id=<external_id> for its conversations.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing contacts ordered by birthday. Replace this request with GET /v1/contacts?limit=<limit>; the new API controls ordering.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>.

Use case: listing contacts. Replace this request with GET /v1/contacts; use page_token for additional pages instead of offset.

Use case: reading detail fields for a contact. Replace this request with GET /v1/contacts/{contact_id}?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: reading one custom detail field for a contact. Replace this request with GET /v1/contacts/{contact_id}?include_details=<key>.

Use case: reading one custom detail field for a contact with a page size. Replace this request with GET /v1/contacts/{contact_id}?include_details=<key>.

Use case: reading selected detail fields for one contact together with that contact’s conversations. Replace this request with GET /v1/contacts/{contact_id}?include_details=<key> for the contact and requested detail fields; repeat include_details for each key from the legacy key[in] filter. Fetch the conversations separately with GET /v1/conversations?contact=<contact_id>.

Use case: listing contacts. Replace this request with GET /v1/contacts?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts without an external id whose address fields are present and whose kundennummer_hellomateo detail field is empty. Replace this request with GET /v1/contacts?external_id[is_null]=true&kundennummer_hellomateo[is_null]=true&limit=<limit>&include_details=kundennummer_hellomateo, then evaluate the address_line1, city, and zipcode checks client-side.

Use case: listing contacts by the bni_start_aufbau detail field. Replace this request with GET /v1/contacts?bni_start_aufbau=<value>&include_details=bni_start_aufbau.

Use case: finding contacts by city. Replace this request with GET /v1/contacts?city=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts by the convercus_account_id detail field. Replace this request with GET /v1/contacts?convercus_account_id=<value>&include_details=convercus_account_id.

Use case: listing contacts created since a timestamp. Replace this request with GET /v1/contacts?include_details=<detail_field>, follow page_token through every page, and apply the created_at boundary client-side. The new API does not currently expose a created_at list filter.

Use case: listing contacts created since a timestamp. Replace this request with GET /v1/contacts?include_details=<detail_field>, follow page_token through every page, and apply the created_at boundary client-side. The new API controls contact ordering.

Use case: listing contacts in one tarif_status created since a timestamp. Replace this request with GET /v1/contacts?tarif_status=<value>&include_details=tarif_status&limit=50, use page_token for additional pages, and apply the created_at boundary client-side. The new API controls contact ordering.

Use case: finding contacts by display name pattern. Replace this request with GET /v1/contacts?search=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. The new API uses normalized substring search instead of the legacy pattern syntax.

Use case: reading one contact by email. Replace this request with GET /v1/contacts/by?email_address=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: finding contacts by email pattern. Replace this request with GET /v1/contacts?search=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. The new API uses normalized substring search instead of the legacy pattern syntax.

Use case: reading one contact by external_id with detail fields. Request GET /v1/contacts/by?external_id=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: reading one contact by external_id with detail fields. Request GET /v1/contacts/by?external_id=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts by external ids. Replace this request with GET /v1/contacts?external_id[in]=<external_ids>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts without an external id. Replace this request with GET /v1/contacts?external_id[is_null]=true&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts without an external id whose kundennummer_hellomateo detail field is present. Replace this request with GET /v1/contacts?external_id[is_null]=true&kundennummer_hellomateo[not_null]=true&include_details=kundennummer_hellomateo.

Use case: listing contacts without an external id whose kundennummer_hellomateo detail field is present and whose zipcode is present. Replace this request with GET /v1/contacts?external_id[is_null]=true&kundennummer_hellomateo[not_null]=true&limit=<limit>&include_details=kundennummer_hellomateo, then evaluate the zipcode check client-side.

Use case: listing contacts with detail fields where external id is present. For a current snapshot, replace this request with GET /v1/contacts?external_id[not_null]=true&limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. If this request is used to check for changes across all contacts, use the upcoming audit log endpoint instead.

Use case: syncing contacts whose blocked state changed after a timestamp. This history-style sync use case will be covered by the upcoming audit log endpoint rather than by a new API contact list filter.

Use case: listing contacts with an external id that are opted in for WhatsApp marketing. When the legacy filter checks whatsapp_marketing_opt_in=true, replace this request with GET /v1/contacts?external_id[not_null]=true&channel_types[in]=whatsapp&require_marketing_opt_in=true&limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: searching contacts with detail fields. Use the List Contacts search parameter for normalized literal substring matching across contact identity fields, or use direct filters such as email, phone number, external_id, or named detail-field filters.

Use case: reading one contact by id. Replace this request with GET /v1/contacts/{id}?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: reading one contact by id. Replace this request with GET /v1/contacts/{id}?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: reading one contact only when its tarif_status detail field matches. Replace this request with GET /v1/contacts/{id}?include_details=tarif_status, then check the returned tarif_status value client-side.

Use case: listing contacts by blocked state with detail fields. If the legacy request filters for is_blocked=false, replace it with GET /v1/contacts?limit=<limit>&include_details=<detail_field> and repeat include_details for each detail field your integration reads. The new API does not currently expose an exact list filter for only blocked contacts, and it controls contact ordering; use page_token for additional pages instead of offset.

Use case: listing contacts by last_delivery_date and was_recalled detail fields. Replace this request with GET /v1/contacts?last_delivery_date[lt]=<timestamp>&was_recalled=<value>&include_details=last_delivery_date&include_details=was_recalled.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

Use case: listing contacts that match any of several channel-specific marketing opt-in clauses. Replace the OR request with one GET /v1/contacts?channel_types[in]=email&require_marketing_opt_in=true&limit=<limit>, one GET /v1/contacts?channel_types[in]=sms&require_marketing_opt_in=true&limit=<limit>, and one GET /v1/contacts?channel_types[in]=whatsapp&require_marketing_opt_in=true&limit=<limit>; merge and deduplicate the contacts client-side. The new API controls contact ordering, so do not rely on the legacy created_at sort; use page_token for additional pages instead of offset.

Use case: finding contacts by tarif_status and any one of several google_calendar_id detail fields. Replace the OR request with one GET /v1/contacts?tarif_status=<tarif_status>&google_calendar_id_01=<calendar_id>&include_details=tarif_status&include_details=google_calendar_id_01 per google_calendar_id detail field; repeat for google_calendar_id_02 through google_calendar_id_10 as needed, then merge and deduplicate the contacts client-side.

Use case: finding contacts by a secondary external ID. Replace this request with GET /v1/contacts/by?secondary_external_id=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: reading one contact by an SMS number. Replace this request with GET /v1/contacts/by?sms_phone_number=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts by the tarif_status detail field. Replace this request with GET /v1/contacts?tarif_status=<value>&limit=<limit>&include_details=tarif_status. The new API controls contact ordering, so do not rely on the legacy display_name sort; use page_token for additional pages instead of offset.

Use case: listing contacts in one tarif_status updated since a timestamp. Replace this request with GET /v1/contacts?tarif_status=<value>&updated_at[gte]=<timestamp>&include_details=tarif_status&limit=50; use page_token for additional pages. The new API controls contact ordering.

Use case: listing contacts by the timify_booking_id detail field. Replace this request with GET /v1/contacts?timify_booking_id=<value>&include_details=timify_booking_id.

Use case: syncing contacts updated after a timestamp. This history-style sync use case will be covered by the upcoming audit log endpoint rather than by a new API contact list filter.

Use case: listing contacts opted in for WhatsApp marketing. When the legacy filter checks whatsapp_marketing_opt_in=true, replace this request with GET /v1/contacts?channel_types[in]=whatsapp&require_marketing_opt_in=true&limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. The new API controls contact ordering, so do not rely on the legacy full_name sort; use page_token for additional pages instead of offset.

Use case: reading one contact by whatsapp. Replace this request with GET /v1/contacts/by?whatsapp_phone_number=<value>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: finding contacts by a whatsapp number pattern. If the pattern is a complete whatsapp number, replace this request with GET /v1/contacts/by?whatsapp_phone_number=<e164_number>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. The new API does not support partial whatsapp matching yet; if your integration depends on partial matching, reach out to us with the concrete use case.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts with the newest contacts first. Replace this request with GET /v1/contacts?limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads. The new API controls contact ordering; use page_token for additional pages.

Use case: listing contacts. Replace this request with GET /v1/contacts?limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing contacts. Replace this request with GET /v1/contacts?include_details=<detail_field>; repeat include_details for each detail field your integration reads; use page_token for additional pages instead of offset.

Use case: creating a contact. Create native and detail fields with POST /v1/contacts. If the request contains email, sms, whatsapp, facebook, or instagram, then upsert each handle with POST /v1/contacts/{id}/identities using channel_type, type, and value; do not send handles as detail fields.

Use case: upserting a contact by external id. Replace this request with GET /v1/contacts/by?external_id=<external_id>, then create or update the contact using the returned result.

Use case: writing a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and send the detail key in the contact body.

Use case: writing a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and send the detail key in the contact body.

Use case: upserting a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and send the detail key in the contact body.

Use case: creating a contact with detail fields. Create native and detail fields with POST /v1/contacts. If the request contains email, sms, whatsapp, facebook, or instagram, then upsert each handle with POST /v1/contacts/{id}/identities using channel_type, type, and value; do not send handles as detail fields.

Use case: merging duplicate contacts. Replace this request with POST /v1/contacts/{id}/merge.

Use case: updating one contact by external id. Replace this request with PATCH /v1/contacts/by?external_id=<external_id>.

Use case: updating one contact by id. Replace this request with PATCH /v1/contacts/{id}.

Use case: writing a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and send the detail key in the contact body.

Use case: updating one contact from a body-provided locator. Replace id-based updates with PATCH /v1/contacts/{id}. For the handle-based locators relevant to this legacy request, call PATCH /v1/contacts/by with email_address, sms_phone_number, or whatsapp_phone_number; external ID locators remain external_id and secondary_external_id.

Use case: updating one contact by id. Replace this request with PATCH /v1/contacts/{id} and send detail fields on the contact body.

Use case: updating one contact by WhatsApp number. Replace this request with PATCH /v1/contacts/by?whatsapp_phone_number=<whatsapp> and send detail fields on the contact body.

Use case: deleting one contact by external id. Replace this request with DELETE /v1/contacts/by?external_id=<external_id>.

Use case: deleting one contact by id. Replace this request with DELETE /v1/contacts/{id}.

Use case: clearing a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and set that detail key to null.

Use case: clearing a custom detail field for one contact. Replace this request with PATCH /v1/contacts/{id} and set that detail key to null.

Use case: deleting one contact by external id. Replace this request with DELETE /v1/contacts/by?external_id=<external_id>.

Use case: deleting one contact by id. Replace this request with DELETE /v1/contacts/{id}.

Use case: creating a custom entity. Replace this request with POST /v1/custom-entities.

Use case: creating a custom entity definition. Replace this request with POST /v1/custom-entity-definitions.

Use case: updating one custom entity by id. Replace this request with PATCH /v1/custom-entities/{id}.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields?entity=<entity>&key=<key>.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields?entity=<entity>&key=<key>&limit=<limit>.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields?key=<key>.

Use case: listing custom field definitions with a page size. Replace this request with GET /v1/custom-fields?key=<key>&limit=<limit>.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields?key[in]=<keys>.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields.

Use case: listing custom field definitions. Replace this request with GET /v1/custom-fields; use page_token for additional pages instead of offset.

Use case: creating a custom field. Replace this request with POST /v1/custom-fields.

Use case: listing deal statuses for an organisation. Replace this request with GET /v1/deal-types?include=statuses and read each deal type’s statuses; omit organisation_id because the API token scopes the organisation.

Use case: listing deal types. Replace this request with GET /v1/deal-types.

Use case: listing deals. Replace this request with GET /v1/deals?limit=<limit>.

Use case: listing deal detail fields. Replace this request with GET /v1/deals?limit=<limit>&include_details=<detail_field>; repeat include_details for each deal detail field your integration reads.

Use case: listing deals with detail fields. Replace this request with GET /v1/deals?include_details=<detail_field>; repeat include_details for each detail field your integration reads.

Use case: listing deals for one contact with detail fields. Replace this request with GET /v1/deals?contact=<contact_id>&limit=<limit>&include_details=<detail_field>; repeat include_details for each detail field your integration reads; use page_token for additional pages instead of offset.

Use case: reading one deal by external id and checking its type. Replace this request with GET /v1/deals/by?external_id=<external_id> and check type_key client-side.

Use case: creating a deal with detail fields. Replace this request with POST /v1/deals and send detail fields on the deal body.

Use case: updating a deal with detail fields. Replace id-based updates with PATCH /v1/deals/{id}; replace external-id based updates with PATCH /v1/deals/by?external_id=<external_id>.

Use case: deleting one deal by external id. Replace this request with DELETE /v1/deals/by?external_id=<external_id>.

Use case: deleting one deal by external id. Replace this request with DELETE /v1/deals/by?external_id=<external_id>.

Use case: listing team members. Replace this request with GET /v1/employees.

Use case: finding employees by full name. Replace this request with GET /v1/employees?full_name=<full_name>.

Use case: reading one employee by id. Replace this request with GET /v1/employees/{id}.

Use case: creating a signed URL for a stored media library file. Replace this request with POST /v1/files/{id}/download_url for files managed by the public files API.

Use case: creating a signed upload URL for a media library file. Replace this request with POST /v1/files/upload_url using { purpose: "media_library", filename }, upload the bytes to the returned URL, and retain the returned file_id.

Use case: formatting a phone number before sending it to another API request. In the new API this separate request is usually unnecessary because endpoints such as imports and message sending format phone numbers internally. POST /v1/format/phone-number remains available as an educational helper when you want to preview normalization behavior.

Use case: identifying the authenticated integration context. Replace this request with GET /v1/me.

Use case: polling one asynchronous import by id. Replace this request with GET /v1/contacts/imports/{id}, GET /v1/deals/imports/{id}, or GET /v1/appointments/imports/{id} according to the imported entity type. Poll the returned status and result counts with backoff.

Use case: submitting an asynchronous contact, deal, or appointment import. Replace this request with POST /v1/contacts/imports/batch, POST /v1/deals/imports/batch, or POST /v1/appointments/imports/batch according to the legacy type. Set source.type to inline, send the record array in source.records, and omit the legacy top-level type. Every successful POST creates a new import job.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

Use case: listing journey executions. This legacy query has no direct public API replacement; contact Mateo support before migrating it.

Use case: starting a journey execution for a contact. Replace this request with POST /v1/journey-executions/start.

Use case: starting journey executions for multiple contacts. Replace this request with POST /v1/journey-executions/start/batch.

Use case: listing communication channels. Replace this request with GET /v1/channels.

Use case: listing communication channels by type and active state. Replace this request with GET /v1/channels?type=<type> and check the returned status client-side; active corresponds to status=active.

Use case: finding communication channels by handle. Replace this request with GET /v1/channels and check the returned handle client-side.

Use case: reading one channel by id. Replace this request with GET /v1/channels/{id}.

Use case: listing communication channels. Replace this request with GET /v1/channels.

Use case: listing communication channels. Replace this request with GET /v1/channels?status=<status>&type=<type>.

Use case: listing communication channels. Replace this request with GET /v1/channels?status=<status>&type=<type>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing communication channels. Replace this request with GET /v1/channels?type=<type>.

Use case: listing communication channels. Replace this request with GET /v1/channels?limit=<limit>.

Use case: listing communication channels. Replace this request with GET /v1/channels?limit=<limit>; use page_token for additional pages instead of offset. The new API controls channel ordering.

Use case: listing communication channels. Replace this request with GET /v1/channels?limit=<limit>.

Use case: listing comments in one conversation. Replace this request with GET /v1/conversations/{conversation_id}/comments?limit=<limit> and use the returned page of comments.

Use case: listing conversation comments in creation order. Replace this request with GET /v1/conversations/{conversation_id}/comments?limit=<limit>; the new API controls comment ordering, so use page_token for additional pages instead of offset.

Use case: reading recent comments in one conversation. If you need the latest comments on that conversation, replace this request with GET /v1/conversations/{conversation_id}/comments?limit=<limit>. If you are polling for comments created after a timestamp, use GET /v1/conversation-events?conversation=<conversation_id>&type=comment.created&created_at[gte]=<timestamp>&limit=<limit>.

Use case: listing recent comments across conversations. Replace this request with GET /v1/conversation-events?limit=<limit> and set the type filter to comment.created.

Use case: listing conversations. Replace this request with GET /v1/conversations.

Use case: reading one conversation by id. Replace this request with GET /v1/conversations/{conversation_id}.

Use case: listing conversations. Replace this request with GET /v1/conversations?channel=<channel_id>&external_id=<external_id>.

Use case: listing conversations. Replace this request with GET /v1/conversations?channel=<channel_id>&unread=<unread>.

Use case: listing conversations. Replace this request with GET /v1/conversations?channel_type=<channel_type>&contact=<contact_id>.

Use case: polling conversation activity after a message timestamp. Replace this with GET /v1/conversation-events?created_at[gte]=<timestamp>&limit=<limit> when the activity stream covers your use case; if you need channel-type-specific latest-message filtering, reach out to us. Use page_token for additional pages instead of offset.

Use case: syncing conversation activity since a timestamp. Replace this with GET /v1/conversation-events?created_at[gte]=<timestamp> where possible; if you need channel-type-specific conversation updates, reach out to us.

Use case: syncing conversation activity since a timestamp. Replace this with GET /v1/conversation-events?created_at[gte]=<timestamp>&limit=<limit> where possible; if you need channel-type-specific conversation updates, reach out to us. Use page_token for additional pages instead of offset.

Use case: listing conversations. Replace this request with GET /v1/conversations?contact=<contact_id>.

Use case: listing conversations for one contact. Replace this request with GET /v1/conversations?contact=<contact_id>&limit=<limit>; use page_token for additional pages.

Use case: listing conversations. Replace this request with GET /v1/conversations?contact=<contact_id>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: reading recent activity for one contact. Replace this request with GET /v1/conversation-events?contact=<contact_id>&limit=<limit> when you need activity changes. If you only need the current conversations for that contact, use GET /v1/conversations?contact=<contact_id>&limit=<limit>.

Use case: reading recent activity for one contact. Replace this request with GET /v1/conversation-events?contact=<contact_id> when you need activity changes. If you only need the current conversations for that contact, use GET /v1/conversations?contact=<contact_id>.

Use case: finding recent conversation activity for conversations with a status/unread condition. Use GET /v1/conversation-events?created_at[gt]=<timestamp>&limit=<limit> for activity polling, then fetch or filter conversations by status and unread state as needed with GET /v1/conversations?status=<status>&unread=<unread>.

Use case: listing conversations. Replace this request with GET /v1/conversations?external_id=<external_id>.

Use case: reading one conversation by id. Replace this request with GET /v1/conversations/{conversation_id}.

Use case: listing conversations by id. Replace this request with GET /v1/conversations?id[in]=<conversation_ids>.

Use case: polling inbound conversation activity within a time window. Replace this with GET /v1/conversation-events?type=message.received&created_at[gte]=<start>&created_at[lte]=<end>&limit=<limit> when inbound message events cover your use case; use page_token for additional pages instead of offset.

Use case: polling conversation activity after a message timestamp. Replace this with GET /v1/conversation-events?created_at[gt]=<timestamp> when the activity stream covers your use case; if you specifically need latest-message filtering, reach out to us.

Use case: polling conversation activity after a message timestamp. Replace this with GET /v1/conversation-events?created_at[gt]=<timestamp>&limit=<limit> when the activity stream covers your use case; if you specifically need latest-message filtering, reach out to us. Use page_token for additional pages instead of offset.

Use case: polling conversation message activity within a time window. Replace this with GET /v1/conversation-events?created_at[gte]=<start>&created_at[lte]=<end>&limit=<limit> when the activity stream covers your use case; use page_token for additional pages instead of offset.

Use case: listing conversations by unread state. Replace this request with GET /v1/conversations?unread=<unread>.

Use case: listing conversations. Replace this request with GET /v1/conversations?unread=<unread>&limit=<limit>.

Use case: reading one conversation with selected channel details. Fetch GET /v1/conversations/{conversation_id}, read its channel_id, then fetch GET /v1/channels/{channel_id}.

Use case: reading one conversation with selected contact details. Fetch GET /v1/conversations/{conversation_id}, read its contact_id, then fetch GET /v1/contacts/{contact_id}?include=identities. Contact email addresses are returned through identities in the new API.

Use case: finding failed messages for a WhatsApp contact. Resolve the contact with GET /v1/contacts/by?whatsapp_phone_number=<number>, then request GET /v1/messages?contact=<contact_id>&status[in]=sending_error,bounce_error,submission_error&include=to&include=conversation.

Use case: listing conversations for a contact external id and unread state, together with contact data. Replace this request with GET /v1/conversations?contact_external_id=<external_id>&unread=<unread>&include=contact.

Use case: listing conversations by unread state together with contact data. Replace this request with GET /v1/conversations?unread=<unread>&include=contact.

Use case: listing conversations for one channel and contact, together with contact data. Replace this request with GET /v1/conversations?channel=<channel_id>&contact=<contact_id>&include=contact.

Use case: listing conversations for one contact together with contact data. Replace this request with GET /v1/conversations?contact=<contact_id>&include=contact.

Use case: loading one conversation with selected contact details. Fetch GET /v1/conversations/{conversation_id}, read its contact_id, then fetch GET /v1/contacts/{contact_id}?include_details=<detail_field>; repeat include_details for each detail field needed.

Use case: listing conversations. Replace this request with GET /v1/conversations?limit=<limit>.

Use case: listing conversations. Replace this request with GET /v1/conversations?limit=<limit>; use page_token for additional pages instead of offset.

Use case: reading tags for one conversation. Replace this request with GET /v1/conversations/{conversation_id}?include=tags.

Use case: listing conversations with a tag. Replace this request with GET /v1/conversations?tag=<tag_id>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: syncing conversation tag changes after a timestamp. Replace this with GET /v1/conversation-events?type[in]=conversation.tag_added,conversation.tag_removed&created_at[gt]=<timestamp>&limit=<limit>, then filter the returned tag resources to the tag ids you care about. Use page_token for additional pages instead of offset.

Use case: checking whether one conversation has a named tag. Resolve the tag with GET /v1/tags, then fetch the conversation with GET /v1/conversations/{conversation_id}?include=tags and check the included tags client-side.

Use case: listing conversation activity events. Replace this request with GET /v1/conversation-events?conversation=<conversation_id>&type=<new_event_type>&created_at[lte]=<timestamp>&limit=<limit>. Map old event types to new API event types before sending type: assign→conversation.assigned, unassign→conversation.unassigned, close→conversation.closed, reopen→conversation.reopened, inbox_change→conversation.inbox_changed, tag→conversation.tag_added, untag→conversation.tag_removed, inbound→message.received, outbound→message.sent, sending_error→message.sending_failed, message_bounce_error→message.delivery_failed, comment→comment.created, action_click→message_action.clicked.

Use case: listing conversation activity events. Replace this request with GET /v1/conversation-events?conversation=<conversation_id>&type=<new_event_type>&limit=<limit>. Map old event types to new API event types before sending type: assign→conversation.assigned, unassign→conversation.unassigned, close→conversation.closed, reopen→conversation.reopened, inbox_change→conversation.inbox_changed, tag→conversation.tag_added, untag→conversation.tag_removed, inbound→message.received, outbound→message.sent, sending_error→message.sending_failed, message_bounce_error→message.delivery_failed, comment→comment.created, action_click→message_action.clicked.

Use case: listing conversation activity events. Replace this request with GET /v1/conversation-events?type=<new_event_type>&created_at[gt]=<timestamp>; map old event types to new API event types before sending type: assign→conversation.assigned, unassign→conversation.unassigned, close→conversation.closed, reopen→conversation.reopened, inbox_change→conversation.inbox_changed, tag→conversation.tag_added, untag→conversation.tag_removed, inbound→message.received, outbound→message.sent, sending_error→message.sending_failed, message_bounce_error→message.delivery_failed, comment→comment.created, action_click→message_action.clicked. Use page_token for additional pages instead of offset.

Use case: listing conversation activity events. Replace this request with GET /v1/conversation-events?conversation=<conversation_id>&type=<new_event_type>&limit=<limit>. Map old event types to new API event types: assign→conversation.assigned, unassign→conversation.unassigned, close→conversation.closed, reopen→conversation.reopened, inbox_change→conversation.inbox_changed, tag→conversation.tag_added, untag→conversation.tag_removed, inbound→message.received, outbound→message.sent, sending_error→message.sending_failed, message_bounce_error→message.delivery_failed, comment→comment.created, action_click→message_action.clicked.

Use case: listing messages. Replace this request with GET /v1/messages.

Use case: listing messages from one employee. Replace this request with GET /v1/messages?author_type=employee&limit=<limit>, then apply the employee id filter client-side.

Use case: reading the latest employee-authored message in a conversation. When author_type=employee, replace this request with GET /v1/messages?conversation=<conversation_id>&author_type=employee&limit=1. Bot and external author filters are not supported; use is_inbound=true for the latest customer message.

Use case: listing campaign messages after a timestamp while excluding statuses and templates. Replace this request with GET /v1/messages?timestamp[gte]=<timestamp>, then keep messages with a campaign and apply the status and template exclusions client-side.

Use case: exporting messages while excluding one contact. Replace this request with GET /v1/messages?contact[neq]=<contact_id>&limit=<limit>; use page_token for additional pages instead of offset. Contactless conversations remain included; add include=conversation and discard rows with a null conversation.contact_id if needed.

Use case: exporting messages associated with contacts. Replace this request with GET /v1/messages?include=conversation&limit=<limit>, keep rows whose conversation.contact_id is not null, and use page_token for additional pages instead of offset.

Use case: loading the latest messages associated with contacts. Replace this request with GET /v1/messages?include=conversation&limit=20 and keep rows whose conversation.contact_id is not null; use page_token to collect more rows when needed.

Use case: listing an offset page of messages for one conversation oldest first. Replace this request with GET /v1/messages?conversation=<conversation_id>&limit=<limit>; use page_token for additional pages instead of offset. The new API controls response ordering.

Use case: listing messages. Replace this request with GET /v1/messages?conversation=<conversation_id>&limit=<limit>.

Use case: listing messages for one conversation oldest first. Replace this request with GET /v1/messages?conversation=<conversation_id>&limit=50. The new API controls response ordering.

Use case: listing messages in one conversation after a timestamp. Replace the legacy created_at filter with the message timestamp filter: GET /v1/messages?conversation=<conversation_id>&timestamp[gte]=<timestamp>.

Use case: listing messages in one conversation before a timestamp. Replace the legacy created_at filter with the message timestamp filter: GET /v1/messages?conversation=<conversation_id>&timestamp[lte]=<timestamp>.

Use case: listing messages. Replace this request with GET /v1/messages?conversation=<conversation_id>&status=<status>.

Use case: listing messages. Replace this request with GET /v1/messages?conversation=<conversation_id>&status=<status>&template=<template_id>.

Use case: listing messages. Replace this request with GET /v1/messages?conversation=<conversation_id>&timestamp[gte]=<timestamp>&limit=<limit>.

Use case: listing messages. Replace this request with GET /v1/messages?conversation=<conversation_id>&timestamp[gte]=<timestamp>.

Use case: listing messages in one conversation within a time window. Replace the legacy updated_at filters with message timestamp filters: GET /v1/messages?conversation=<conversation_id>&timestamp[gte]=<start>&timestamp[lte]=<end>.

Use case: listing messages after a timestamp by direction and status. Replace the legacy created_at filter with the message timestamp filter: GET /v1/messages?timestamp[gte]=<timestamp>&is_inbound=<true_or_false>&status[in]=<statuses>.

Use case: reading one message by id. Replace this request with GET /v1/messages/{id}.

Use case: listing messages. Replace this request with GET /v1/messages?id[in]=<message_ids>.

Use case: listing messages after a timestamp. Replace this request with GET /v1/messages?timestamp[gte]=<timestamp>&limit=<limit>.

Use case: listing messages. Replace this request with GET /v1/messages?timestamp[gte]=<timestamp>&limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing recent messages after a timestamp. Replace this request with GET /v1/messages?timestamp[gte]=<timestamp>&limit=<limit>; the new API controls response ordering.

Use case: listing messages in one conversation after a timestamp with employee author details. Replace the created_at filter with GET /v1/messages?conversation=<conversation_id>&timestamp[gt]=<timestamp>. Retrieve employee details separately when needed.

Use case: listing messages. Replace this request with GET /v1/messages?limit=<limit>&include=conversation; use page_token for additional pages instead of offset.

Use case: listing messages in a bounded synchronization window with conversation details. Replace the legacy created_at and updated_at bounds with message timestamp filters: GET /v1/messages?timestamp[gt]=<start>&timestamp[lt]=<end>&limit=<limit>&include=conversation; use page_token for additional pages instead of offset.

Use case: listing messages for a template after a timestamp. Replace the legacy updated_at filter with the message timestamp filter: GET /v1/messages?template=<template_id>&timestamp[gt]=<timestamp>&limit=<limit>&include=conversation; use page_token for additional pages instead of offset.

Use case: incrementally mirroring inbound and outbound messages with author and contact context. Poll GET /v1/conversation-events?type[in]=message.received,message.submitted&created_at[gt]=<last_sync>&limit=100, then hydrate each page’s message resource IDs with GET /v1/messages?id[in]=<message_ids>&include=author&include=conversation. Use is_inbound for direction and add author_type=employee only when the requested author type is employee; bot and external author filters are not supported.

Use case: listing messages. Replace this request with GET /v1/messages?campaign=<campaign_id>&include=conversation.

Use case: listing inbound or outbound messages after a timestamp. Replace the legacy created_at filter with the message timestamp filter: GET /v1/messages?timestamp[gt]=<timestamp>&is_inbound=<true_or_false>&limit=<limit>&include=conversation; use page_token for additional pages instead of offset.

Use case: listing inbound or outbound messages in a time range with conversation details. Replace created_at filters with message timestamp filters and use GET /v1/messages?timestamp[gt]=<start>&timestamp[lt]=<end>&is_inbound=<true_or_false>&limit=<limit>&include=conversation; use page_token for additional pages instead of offset. Retrieve employee details separately when needed.

Use case: reporting messages, recipients, actions, and conversation data for selected channels. Replace this request with GET /v1/messages?channel[in]=<channel_ids>&timestamp[gte]=<time>&include=to&include=actions&include=conversation&limit=<limit>; use include=from for inbound recipients and page_token for additional pages instead of offset. The response includes channel_type, so omit that filter.

Use case: reporting messages, recipients, and actions for selected channels. Replace this request with GET /v1/messages?channel[in]=<channel_ids>&timestamp[gte]=<time>&include=to&include=actions&limit=<limit>; use include=from for inbound recipients and page_token for additional pages instead of offset. The response includes channel_type, so omit that filter.

Use case: listing messages. Replace this request with GET /v1/messages?limit=<limit>.

Use case: listing messages. Replace this request with GET /v1/messages?limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing messages. Replace this request with GET /v1/messages?limit=<limit>; use page_token for additional pages instead of offset.

Use case: listing newest messages. Replace this request with GET /v1/messages?limit=<limit>; use timestamp filters for time-based message queries.

Use case: listing messages. Replace this request with GET /v1/messages?limit=<limit>.

Use case: listing newest messages. Replace this request with GET /v1/messages; use timestamp filters for time-based message queries.

Use case: listing messages. Replace this request with GET /v1/messages.

Use case: tracking recently clicked message actions. Replace this request with GET /v1/conversation-events?type=message_action.clicked&created_at[gte]=<last_seen_created_at>&limit=<limit>; use page_token and created_at for pagination instead of message_action.updated_at.

Use case: listing connected messaging providers. Replace this request with GET /v1/providers. Optionally filter by status and type with GET /v1/providers?status=<status>&type=<type>.

Use case: reading provider approval records for message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Use GET /v1/templates?include=latest_version to list templates with approval intent on their latest versions, or GET /v1/templates/{template_id}/versions to inspect all versions of one template. The request_approvals field only indicates whether provider approvals should be requested; it does not expose provider IDs, current approval status, external IDs, rejection reasons, or categories. If you need provider-specific approval status in the new API, contact your hellomateo contact person so we can add the required support for your use case.

Use case: reading provider approval records for one message template. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Use GET /v1/templates/{template_id}/versions to inspect the template’s versions. The request_approvals field only indicates whether provider approvals should be requested; it does not expose provider IDs, current approval status, external IDs, rejection reasons, or categories. If you need provider-specific approval status in the new API, contact your hellomateo contact person so we can add the required support for your use case.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

Use case: reading provider approval records for message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Use GET /v1/templates?include=latest_version to list templates with approval intent on their latest versions, or GET /v1/templates/{template_id}/versions to inspect all versions of one template. The request_approvals field only indicates whether provider approvals should be requested; it does not expose provider IDs, current approval status, external IDs, rejection reasons, or categories. If you need provider-specific approval status in the new API, contact your hellomateo contact person so we can add the required support for your use case.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

Use case: listing tags. Replace this request with GET /v1/tags?limit=<limit>; use page_token for additional pages instead of offset.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading one message template by ID. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Validate the preview response before switching production traffic.

Use case: reading one message template by ID. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Validate the preview response before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: reading or searching message templates. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Preview filters differ from some legacy filters, so validate your use case before switching production traffic.

Use case: creating a comment in one conversation. Replace this request with POST /v1/conversations/{conversation_id}/comments.

Use case: adding a tag to one conversation. Replace this request with PUT /v1/conversations/{conversation_id}/tags/{tag_id}.

Use case: sending a message. Replace this request with POST /v1/messages/send.

Use case: creating a message template. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Use the preview schema to prepare the new request, but keep this legacy write in production until the new API is released.

Use case: changing one conversation state. Replace inbox_id with POST /v1/conversations/{conversation_id}/move, assignee_id with assign or unassign, and status with open or close.

Use case: removing a tag from one conversation. Replace this request with DELETE /v1/conversations/{conversation_id}/tags/{tag_id}.

Use case: deleting one message by id. Replace this request with DELETE /v1/messages/{message_id}.

Use case: deleting one message only when it has a specific status. Replace this request by first checking GET /v1/messages/{id}, then inspect the returned status client-side and call DELETE /v1/messages/{message_id} only if it matches.

Use case: deleting a message template. Preview documentation for the new Templates API is available now. Use it to start updating your integration. We are working hard on the production release and expect it by mid-August 2026. Use the preview schema to prepare the new request, but keep this legacy write in production until the new API is released.

Use case: listing opt-in groups. Replace this request with GET /v1/opt-in-groups.

Use case: listing opt-in groups for an organisation. Replace this request with GET /v1/opt-in-groups; omit organisation_id because the API token scopes the organisation.

Use case: listing locations. Replace this request with GET /v1/locations.

Use case: listing active or recently sent campaigns for reporting. Replace this request with GET /v1/campaigns?status=<status>&last_sendout_date[gte]=<time>&limit=100. For multiple statuses, use GET /v1/campaigns?status[in]=scheduled,done&last_sendout_date[gte]=<time>&limit=100. This endpoint returns one-time campaigns only.

Use case: listing opt-in state. Replace this request with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Use case: listing opt-in state together with the related contact. Replace this request with GET /v1/opt-ins?include=contact.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Use case: listing opt-in state together with the related contact. Replace this request with GET /v1/opt-ins?limit=<limit>&include=contact.

Use case: listing opt-in state together with the related contact. Replace this request with GET /v1/opt-ins?limit=<limit>&include=contact; use page_token for additional pages instead of offset.

Use case: listing opt-in state together with the related contact. Replace this request with GET /v1/opt-ins?include=contact; use page_token for additional pages instead of offset.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Replace this history-style opt-in sync with GET /v1/audit-logs using action[in]=opt_in.created,opt_in.status_changed,opt_in.deleted, subject_type=opt_in, bounded occurred_at[gte] and occurred_at[lte] RFC3339 timestamps, and include=subjects. Follow https://developers.getmateo.com/docs/recipes/poll-opt-in-changes for overlap windows, deduplication, chronological replay, and checkpoints. The audit-log endpoint does not support legacy status, channel_type, or contact filters; apply those filters to emitted changes or hydrated current resources client-side. Results are descending, so fetch every next_page_url instead of using offset. Periodically reconcile with GET /v1/opt-ins.

Use case: listing opt-in state. Replace this request with GET /v1/opt-ins?limit=<limit>.

Use case: listing opt-in state, optionally together with the related contact. Replace this request with GET /v1/opt-ins?limit=<limit>&include=contact; use page_token for additional pages instead of offset.

Use case: listing opt-in state. Replace this request with GET /v1/opt-ins; use page_token for additional pages instead of offset.

Use case: listing webhooks. Replace this request with GET /v1/webhooks.

Use case: listing webhooks by event. Replace this request with GET /v1/webhooks and filter by event client-side.

Use case: creating a webhook. Replace this request with POST /v1/webhooks.

Use case: deleting one webhook by id. Replace this request with DELETE /v1/webhooks/{id}.

We are working on public API support for this request pattern. If this request is important for your migration, contact us with your use case.

Use case: creating a broadcast campaign. Replace this request with POST /v1/campaigns.

Use case: receiving SAP Emarsys requests that send templated messages. Replace this request with POST /webhooks/sapemarsys/send-message.