Standard operations
What basic concepts apply to all resources in our platform?
While each resource serves different business purposes, they all share common fields and actions that work consistently across the platform.
Deactivation (soft delete)
Instead of permanently deleting resources, we use deactivation to preserve data for audit and compliance purposes while preventing further use.
Each resource has deactivation and reactivation endpoints accessed via PATCH .../resource/:id/deactivate and PATCH .../resource/:id/reactivate .
Deactivation affects the following parameters:
activeparameter switches tofalsedeactivated_atparameter records the timestamp of deactivationdeactivation_reasonparameter carries a free-text explanation (optional field for your audit records in the request body of deactivation request)
When a resource is deactivated:
You can still retrieve it via
GETendpoints (both individual and list views), and it is still shown in lists by defaultMost API actions will verify that resources are active before allowing operations
Reactivation is available if you accidentally deactivate a resource. Depending on the resource type, additional checks may apply before allowing deactivation or reactivation.
External reference
Most resources support an external_reference string parameter to help you maintain connections between our platform and your internal systems. Use this field to store your own system's ID for the resource, making data synchronization easier.
Audit trails access
Since our platform tracks all changes for compliance and regulatory reasons, each resource provides a dedicated GET .../resource/:id/events endpoint to view its complete change history.
Each event record includes:
Type of event that occurred
Precise timestamp of the event
Content of the change driven by this event
User who performed the action, triggering the event
Last updated

