# 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}`.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developers.bead.xyz/entity-management/terminal-management/terminal-lifecycle-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.