> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/get-started/concepts/projects.md).

# Projects

A project is the unit of traffic segmentation, approval, and reporting in IDlayr. Every API call is made in the context of a project. Each project has its own credentials, its own approval workflow, its own allowed networks, and its own analytics.

## What a project represents

The meaning of a project depends on your relationship with IDlayr.

### Direct customers

A project is a **use case** — one specific way you're using IDlayr. If you use IDlayr in three places — onboarding, login, and high-value transaction protection — you have three projects.

Each use case has its own approval flow with IDlayr (and where applicable, with the mobile network operators). Splitting them into separate projects keeps approvals, traffic limits, and analytics scoped to the use case they apply to.

### Channel partners

A project is a **bundle of one final customer and one use case**. For a channel partner with five end customers each using IDlayr in two ways, that's ten projects.

Naming convention: `<CustomerName>-<UseCase>`. For example:

* `CompanyX-Onboarding`
* `CompanyX-Pay`
* `CompanyY-Signup`

Splitting by (customer × use case) lets the channel partner — and IDlayr — segment traffic, run approvals, and report cleanly per customer per use case.

## What's scoped to a project

| Scoped to project                                 | Notes                                                       |
| ------------------------------------------------- | ----------------------------------------------------------- |
| OAuth2 credentials (`client_id`, `client_secret`) | One pair per project                                        |
| Allowed networks                                  | The networks this project is authorised to use              |
| Project mode                                      | Live or sandbox                                             |
| Rate limits                                       | Per project, not per workspace                              |
| Analytics and reporting                           | Traffic, success rates, and errors are reported per project |

## Identifiers

Projects are identified by a `project_id` (UUID). Most API operations don't require you to pass this explicitly — the OAuth2 token you use to authenticate already encodes which project you're acting on behalf of.

## Creating a project

Projects can be created two ways:

* **Via the Enterprise Portal** — any user of your organisation with the appropriate role can create a project from the portal UI.
* **Via the API** — using your **workspace credentials**, you can create projects programmatically.

Every new project is **auto-created in sandbox mode**. Sandbox mode is immediately usable for development and testing — no approval gate. You can switch a project to **live mode** at any time, but live traffic will only be served once your organisation has been **approved on one or more carriers** for the relevant product(s). Approval is per organisation and per carrier; once granted, it applies to live-mode projects without an additional per-project approval step.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.idlayr.com/get-started/concepts/projects.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.