Terminal Lifecycle (Concepts)

A terminal moves through a simple lifecycle: creation, configuration, active use, updates, and retirement. This page explains the typical phases and the API calls commonly used at each step.

Use the top-level terminal creation pattern:

• POST /Terminals

Include locationId in the request body when creating a terminal rather than calling a nested location terminal creation URL.

Overview

A typical terminal lifecycle looks like this:

1. Create the terminal

2. Configure or update terminal settings

3. Use the terminal in active operations

4. Manage related webhook configuration if applicable

5. Retire or delete the terminal when it is no longer needed

The allowed methods for an individual terminal resource are:

• GET /Terminals/{id}

• PUT /Terminals/{id}

• DELETE /Terminals/{id}

Do not use PATCH /Terminals/{id} unless and until the OpenAPI spec explicitly supports it.

Phases

1. Create

Create a terminal with:

• POST /Terminals

Provide the required terminal details in the request body, including locationId.

Use this phase when you are provisioning a terminal for a location and preparing it for operational use.

2. Retrieve

Retrieve terminal details with:

• GET /Terminals/{id}

Use this to confirm the current terminal record, review configuration, or verify identifiers before making updates.

3. Update

Update an existing terminal with:

• PUT /Terminals/{id}

Use this when you need to change terminal settings or maintain the terminal record.

If webhook configuration is managed separately in your implementation, use the webhook-specific endpoint documented for that purpose, for example:

• PUT /Terminals/{id}/webhook

Do not use malformed references such as:

• PUT /Terminals/{id}PUT

• PATCH /Terminals/{id}

4. Active Use

Once created and configured, the terminal can be used in the flows supported by your implementation, such as payment and operational workflows tied to that terminal.

During active use, you may periodically retrieve the terminal record to confirm its current configuration:

• GET /Terminals/{id}

And update it as needed:

• PUT /Terminals/{id}

5. Retirement

When a terminal is no longer needed, remove it with:

• DELETE /Terminals/{id}

Before deleting a terminal, confirm it is no longer required by any active workflow, integration, or reporting dependency.

Recommended Lifecycle Pattern

A common lifecycle sequence is:

1. Create the terminal with POST /Terminals

2. Confirm the record with GET /Terminals/{id}

3. Update settings with PUT /Terminals/{id} as needed

4. Maintain any related webhook configuration through its documented endpoint

5. Delete the terminal with DELETE /Terminals/{id} when it is retired

Endpoint Notes

Use these endpoint forms on this page:

• POST /Terminals

• GET /Terminals/{id}

• PUT /Terminals/{id}

• DELETE /Terminals/{id}

If webhook management applies, reference the webhook endpoint exactly as documented elsewhere in the terminal management docs.

Avoid these incorrect forms:

• PATCH /Terminals/{id}

• PUT /Terminals/{id}PUT

Summary

The terminal lifecycle is centered on a straightforward create, retrieve, update, and delete pattern. Create terminals at the top level with POST /Terminals, include locationId in the request body, update terminals with PUT /Terminals/{id}, and retire them with DELETE /Terminals/{id}.