Create or update a contact by e-mail
Creates or updates one contact by e-mail and returns it whole, as get_contact does. Call it to push a contact from another system, such as a CRM, without looking it up first; for many contacts at once, upsert_contacts.
The contact is found by email, without case, and updated; when the address is free it is created. The address of a deleted contact restores that contact with its old data and applies the request over it. result says which: created and restored answer 201, updated and unchanged (nothing to change, nothing written) answer 200.
A field left out is kept; null clears first_name, last_name, phone, country, timezone and language; fields are keyed by field ids from list_contact_fields, merged by key, and null removes a value. Tags go by name, compared without case: add_tags adds them and creates a tag the site does not have, remove_tags takes them off; tags not named stay. changed names the fields that were written.
Status: subscribed is allowed from unsubscribed, and subscribes again a contact who opted out, as the admin does; leave status out to keep what the contact chose. unsubscribed is allowed from subscribed or from awaiting double opt-in. A bounced contact changes status only with a new e-mail, and a contact awaiting double opt-in is never subscribed here. A status change that is not allowed does not stop the rest: the other fields are written and reason says why.
A new contact is subscribed unless status says unsubscribed, which stores it as never subscribed; it cannot be created bounced. Its source is api, with the API key as id, or the user when the call is made with a user's access token. A contact created here starts "new contact" automations when subscribed and emits contact.created; a restored one does neither. Its e-mail is checked in the background. A found contact keeps the stored case of its e-mail and its source.
Request
- Base URLhttps://api.getsitecontrol.com
- AuthHTTP bearer
Path parameters
Headers
Makes a retry of a POST safe: a repeat with the same key, body and GSC-Version returns the stored response with Idempotency-Replayed: true instead of running again. The key protects against repeated execution while the key store works. Saving the change and storing the response under the key are not atomic: if the process or the key store fails between them, the change is kept, the key is released after 15 minutes and a retry runs the request again. After a timeout or a 5xx, read the resource to check the result before retrying. 5xx and 429 responses and responses over 256 KB are not stored, so a repeat runs the request again. A key is kept for 24 hours. The same key with another body or version is 422; a repeat while the first request runs is 409.
Request body
Response
The contact existed: updated, or nothing to change
Changes
No recorded changes to this operation across all 1 revision of this API.