> For the complete documentation index, see [llms.txt](https://docs.digitalapi.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitalapi.ai/developer-portal/resources/developer-resources.md).

# Developer resources

Beyond the catalog, the portal gives consumers the supporting material they need to integrate successfully: documentation, guides, a blog, a support route, and an in-portal notifications inbox. A consumer turns to these surfaces while learning how an API works, working through an integration, and staying informed about changes that affect their applications.

![Figure 1. The documentation home in the developer portal.](/files/ijTNvR2wDKwbbFjIAIGy)

### What you see

The portal's top navigation carries the resource areas alongside the catalog, plus a bell icon for notifications when signed in.

* **Documentation**: a home for quick-start material, authentication and authorization guidance, and reference content that applies across the published APIs.
* **Guides**: longer how-to articles that walk a consumer through common integration tasks from start to finish.
* **Blog**: announcements, best-practice articles, and product updates that keep consumers informed over time.
* **Support**: a route to raise questions and get help, including a contact form where the provider has enabled one.
* **Notifications**: a bell icon in the top navigation that opens an in-portal inbox of messages addressed to the signed-in consumer.

### Documentation, guides, and blog

These three areas are reference content authored on the provider side and read by consumers:

1. Open **Documentation** to find quick-start and authentication guidance before making a first call.
2. Move to **Guides** when a task needs an end-to-end walkthrough rather than reference lookup.
3. Browse the **Blog** for announcements and product updates, newest first.

Documentation and guides are public reading surfaces, so a visitor can study how the APIs work before creating an account. The guides area is shown below.

![Figure 2. The guides area, with end-to-end integration walkthroughs.](/files/L5iUsuVxU35sueSCH1x1)

### Raise a support request

When a consumer needs direct help:

1. Open **Support** from the top navigation.
2. Use the contact route or form the provider has enabled to describe the question.
3. Submit. The request reaches the provider's support channel for a response.

{% hint style="info" %}
**Note:** The support contact form appears only where the provider has enabled it. Some portals point support at an external help desk or email address instead.
{% endhint %}

### Notifications

A signed-in consumer receives in-portal notifications in the inbox opened from the bell icon:

* **Subscription approvals**: a message when a pending subscription is approved or declined by the provider.
* **Credential changes**: confirmation when an application's secret is rotated or its credentials change.
* **Announcements**: provider broadcasts such as new API releases, deprecations, or maintenance windows.

The bell shows an indicator when unread items are waiting, and opening the inbox lists each message with its context.

### Verify

* Documentation, guides, and blog pages load and render their content for both signed-in and signed-out visitors.
* A submitted support request returns a confirmation, or the external help route opens as configured.
* A subscription approval or credential rotation produces a matching entry in the notifications inbox.

### Options and variations

* **Public versus signed-in views**: documentation, guides, and blog are readable without an account; the notifications inbox and the bell appear only after sign-in.
* **Provider configuration**: the presence of a contact form, the set of notification types, and the depth of documentation depend on what the provider has published and enabled.

{% hint style="success" %}
**Tip:** Documentation, guides, and blog content are authored on the provider side. Keeping them current is the most effective way to reduce inbound support questions and speed consumer adoption.
{% endhint %}


---

# 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.digitalapi.ai/developer-portal/resources/developer-resources.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.