# APIContext Docs > Documentation for APImetrics by APIContext: API performance monitoring, testing, conformance, and analytics. Covers getting started, guides, concepts, the CLI, and the REST API reference. Full text of every public page, generated at build time. Index: https://docs.apicontext.com/llms.txt --- # APImetrics by APIContext Documentation > Monitor, test, and analyze your APIs. Start here, follow a guide, understand the concepts, or drive everything from the CLI. Source: https://docs.apicontext.com This platform helps you understand how your applications and services actually behave. It makes planned requests to API endpoints, HTTP endpoints, websites, MCP servers, and other endpoint destinations. Calls can be individual or sequenced into multi-step workflows, and are run from external cloud locations. The platform replicates the same security configuration of a real user, then measures performance and surfaces integrated analyses and reports. For a high-level overview of the platform's capabilities, see the [product overview](https://apicontext.com/product-overview). ## Find your way around - **[Start Here](https://docs.apicontext.com/index.md)**: Guided tutorials. Follow these first to get a working result: monitor your first API end to end. - **[Guides](https://docs.apicontext.com/guides/add-a-monitor.md)**: Task-oriented how-tos. Monitor types ([HTTP](https://apicontext.com/features/api-monitoring), [Browser](https://apicontext.com/features/website-monitoring), [MCP](https://apicontext.com/features/ai-monitoring)), authentication, scheduling, alerting, analytics, conformance, SLOs, projects, workflows, integrations, and importing. - **[Concepts](https://docs.apicontext.com/concepts/casc-score.md)**: Background and explanations: monitors, workflows, scheduling, the CASC quality score, access roles, conformance, projects, and collections, and the SLA model. - **[CLI](https://docs.apicontext.com/cli.md)**: Drive APImetrics from the command line: install the binary, authenticate, and manage monitors, projects, and workflows. - **[Reference](https://docs.apicontext.com/reference/intro.md)**: The full REST API reference (OpenAPI), pagination, error shapes, and authentication tokens. - **[Changelog](https://docs.apicontext.com/changelog.md)**: What changed and when. ## Key concepts at a glance APImetrics organizes your Monitors by **projects** (a group of Monitors), **collections** (a group of projects), and **organizations** (usually an enterprise). Create your own collections, or subscribe to collections we manage and curate for you. Invite multiple people to your projects with role-based access at five levels, from Owner to Viewer. See [Access roles](https://docs.apicontext.com/concepts/access-roles.md). ## Pricing Plans, usage-based billing, and feature availability are described on the APIContext pricing page: **[apicontext.com/pricing](https://apicontext.com/pricing)**. ## Support For support questions, visit [apicontext.com/support](https://apicontext.com/support) and open a request. --- # Monitor your first API > Create your first API monitor and read its results in under 10 minutes. Source: https://docs.apicontext.com/monitor-your-first-api ## What you'll achieve By the end of this tutorial you will have a running API monitor that calls a real endpoint on a schedule, and you will be able to find and read its results, including the pass/fail status, latency breakdown, and response details. ## Before you start - An APIContext account: free tier is fine. [Sign up at client.apimetrics.io](https://client.apimetrics.io) - An API endpoint to test. This tutorial uses `https://httpbin.org/get`: a public, always-on endpoint that returns a simple JSON response with no authentication required. --- ## Step 1: Create a project Everything in APIContext lives inside a **Project**. When you log in you land on the **Collections** page, which lists all your projects grouped by organization. 1. In the top bar, open the **Organization** picker and select your organization (also labeled **Collection** in some parts of the UI: they refer to the same entity). 2. Click the **Project** picker and choose **+ Add Project**. 3. Give your project a name (for example, **My First Monitor**) and save it. 4. The app will open your new project at **Project Overview** (`/home/`). --- ## Step 2: Add a monitor A monitor is a configured API request that APIContext runs on your behalf. The Monitors list is found under **Configure Monitoring** in the left sidebar. 1. In the left sidebar, under **Configure Monitoring**, click **Monitors**. The page heading reads **Monitors** and lists all monitors defined in this project. 2. Click **+ Add New API Call**. The **Create New API Call** panel opens. 3. Fill in the fields: - **Method**: leave it set to **GET** (the default). - **URL**: enter `https://httpbin.org/get`. - **Name**: enter something descriptive, for example `httpbin GET`. 4. Leave all other fields at their defaults. No authentication is needed for this endpoint. 5. Click **Create and Edit**. The monitor is created and opens in the monitor edit form. (**Create Monitor** creates it without opening it.) Your monitor now appears in the Monitors list. --- ## Step 3: Run it once to verify Before putting the monitor on a schedule, confirm it works with a manual run. 1. On the monitor edit form (or from the Monitors list, open the monitor and go to its **Edit** tab), locate the **Run Monitor Now** button in the right rail. 2. Click **Run Monitor Now**. APIContext sends the request from a remote Node. There will be a short delay, typically a few seconds, while the call travels to the Node and back. 3. The right rail updates to show **Last result**: you should see **Passed**, **HTTP 200**, and a latency value. If the result shows a failure, double-check the URL for typos. `https://httpbin.org/get` should always return HTTP 200. --- ## Step 4: Add the monitor to a schedule A manual run is a one-off check. To make this a true monitor, something that runs automatically and continuously, you need to add it to a **Schedule**. 1. In the left sidebar, under **Configure Monitoring**, click **Schedules**. 2. Click **+ New Schedule**. A modal opens with tabs **Edit Schedule** and **Node Locations**. 3. On the **Edit Schedule** tab, fill in: - **Name**: for example, `Every 5 minutes – worldwide`. - **Frequency**: select **12 per hour (once every 5 minutes)** (the highest frequency on the free tier). - **Node Selection**: leave it set to **Worldwide**. 4. Click **Save changes**. 5. The new schedule card appears in the Schedules list. Click the **Scheduled Monitors** count on the card to open the monitors dialog. In the **Add to Schedule:** row, choose your `httpbin GET` monitor from the **Select Monitor or Workflow** picker and click **Add**. Your monitor is now running. Results will accumulate every five minutes. --- ## Step 5: Read your first results Results appear in two places: on the monitor itself, and in the project-wide results view. ### On the monitor 1. In the left sidebar, click **Monitors**. 2. Click the row for `httpbin GET` to expand it, then open the **Results** tab (`/tests/test//results`). 3. Each row is one execution. The columns show: - **Start time**: when the call was made. - **Result Class**: `Passed`, `Warning`, or `Failed`. - **HTTP status**: should be `200`. - **Total time**: end-to-end response time in milliseconds. 4. Click a row to open the full result detail. You will see: - A **call result summary** (pass/fail, HTTP code, trigger reason). - **Call duration breakdown**: DNS lookup, TCP connect, processing time, and total time. - The **request** that was sent and the **response** that came back, including the response body. ### Project-wide To see results across all monitors in the project: 1. In the left sidebar, under **INVESTIGATE**, click **All Call Results**. The page is titled **Results / Monitor Results** and shows every request made in this project. 2. Use the **Result category** filter to narrow to `Passed` or `Failed` runs, and the **Location** filter to see results from a specific node. ### Project Overview summary On the **Project Overview** page (`/home/`), the **Monitors in Schedules** table shows a live summary row for your monitor with columns **Quality**, **Availability %**, **Slow %**, and **Avg. Total latency**. After a few runs these numbers will populate and give you an at-a-glance health view. --- ## What's next? You have a working monitor running on a schedule. Here are the natural next steps: **Understand what you just built** - [Quality score explained](https://docs.apicontext.com/concepts/casc-score.md): how the 0–9.99 CASC score is calculated **Go deeper on monitoring** - [Add authentication to a monitor](https://docs.apicontext.com/guides/authentication-settings.md): set up OAuth 2, API key, or Fixed Bearer Token - [Set up alerts and webhooks](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md): get notified on failures via email, Slack, or PagerDuty - [Configure project conditions](https://docs.apicontext.com/guides/set-conditions.md): define what counts as a pass, warning, or failure for HTTP status, headers, and latency - [Put your monitor on a schedule](https://docs.apicontext.com/guides/schedule-monitors.md): run automatically on a recurring interval **Expand coverage** - [Create a workflow](https://docs.apicontext.com/guides/creating-a-workflow.md): chain multiple monitors into a sequence - [Add an OpenAPI specification](https://docs.apicontext.com/guides/importing-api-calls.md): import your API spec and let APIContext measure conformance - [Set up browser monitoring](https://docs.apicontext.com/guides/add-a-monitor/browser-monitors.md): capture Core Web Vitals with real headless browsers - [Monitor AI infrastructure](https://apicontext.com/features/ai-monitoring): test MCP servers --- # Guides > Task-oriented guides for monitoring APIs, HTTP endpoints, websites, MCP servers, workflows, alerting, analytics, and integrations. Source: https://docs.apicontext.com/guides Task-oriented instructions for setting up APIContext, building monitors, and acting on what they find. New to APIContext? Start with [Monitor your first API](https://docs.apicontext.com/monitor-your-first-api.md). The guides are grouped by task. Each group starts with the page most people need first. | Group | Use it to | Start with | |---|---|---| | Projects, team, and access | Set up projects and organizations, invite people, and copy or move resources | [Projects](https://docs.apicontext.com/guides/projects.md) | | Create monitors | Add API, browser, MCP, and Postman monitors, or import them from a spec | [Add an API monitor](https://docs.apicontext.com/guides/add-a-monitor/add-api-call.md) | | Authentication | Give monitors the credentials, tokens, and certificates an API needs | [Monitor Authentication](https://docs.apicontext.com/guides/monitor-authentication.md) | | Workflows, variables, and assertions | Chain calls, pass values between them, and decide what counts as a pass | [Workflows](https://docs.apicontext.com/guides/creating-a-workflow.md) | | Schedule and run monitors | Run monitors on a schedule or on demand, pause them for maintenance, and add private nodes | [Managing Schedules](https://docs.apicontext.com/guides/setting-and-managing-schedules.md) | | Results and analytics | Read results, dashboards, reports, and the CASC score | [Understanding the Results](https://docs.apicontext.com/guides/view-results.md) | | Alerts and notifications | Get told when a monitor fails, by email, webhook, Slack, Teams, or PagerDuty | [Setting Alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md) | | Conformance and SLOs | Check APIs against standards and specs, and track service-level objectives | [Conformance](https://docs.apicontext.com/guides/conformance.md) | | Integrations and data export | Send results to observability tools and bring in third-party data | [Org-level Integrations](https://docs.apicontext.com/guides/integrations/org-level-integrations.md) | | API and CLI | Automate APIContext from scripts, pipelines, and agents | [Install and set up the CLI](https://docs.apicontext.com/guides/install-and-set-up-the-cli.md) | | Help and support | Find answers, contact support, and follow platform status | [FAQs](https://docs.apicontext.com/guides/faqs.md) | For what a monitor, workflow, or result is, see [Concepts](https://docs.apicontext.com/concepts.md). For every endpoint and field, see the [API reference](https://docs.apicontext.com/reference/intro.md) and the [CLI reference](https://docs.apicontext.com/cli.md). --- # Basic Navigation > How to find things in the two key menus: the side navigation menu for making and running monitors, and the top navigation menu. Source: https://docs.apicontext.com/guides/basic-navigation ## Side Bar Navigation Menu The side navigation menu is focused on the core functionality of making and running monitors and you'll find everything to do with seeing information on the calls, creating, importing, scheduling, and authentication through to alerting.\ In sequence the menu sections are: * Project picker - navigate between your projects * Home Page and Customizable Dashboard * Analytics & Reporting - if you only have view access to projects * Configure Monitoring - everything you need to make, create, run, and configure monitors, including **Alerts & Webhooks** for email and webhook alerts * Advanced settings such as environment variables and files ![APImetrics portal with the left side navigation menu highlighted, showing Investigate, Configure Monitoring, and Project Settings sections](https://docs.apicontext.com/img/3f477e8-Side_Navigation.webp) ## Project Picker Click on the project name to get a list of the projects you have access to. All users will have view access to at least one project. ![Top-right project picker dropdown expanded to list the projects the user can access](https://docs.apicontext.com/img/feb9215-project_picker.webp) ## Switch organizations To move between the organizations you belong to, see [Switch organizations](https://docs.apicontext.com/guides/projects/switch-organizations.md). ## Top Navigation Menu The top right navigation menu handles project and account admin features. Here you can: * Manage your org (if you're an enterprise client) * Manage your projects and invite other users to the project * Manage your subscription\\ * See Audit Logs * See Alerts and Webhooks * Set Latency SLA terms * See all your account notifications * Edit your user settings * Choose which emails you receive, in [Email Settings](https://docs.apicontext.com/guides/projects/manage-email-settings.md) ![APImetrics portal with the top navigation bar highlighted, showing the organization and project selectors and account menu](https://docs.apicontext.com/img/56078fd-Top_Navigation.webp) --- # Network Conformance Checks > Configure TLS certificate expiry monitoring, CDN allowlists, and geo-fencing checks for a project in the Manage Network Checks section of Conformance Settings. Source: https://docs.apicontext.com/guides/network-conformance [Network monitoring](https://apicontext.com/features/network-monitoring) conformance checks extend your monitors to verify not just whether an API responds correctly, but whether the underlying network and certificate infrastructure meets your requirements, including DNS, TLS handshake, CDN routing, and cross-cloud performance. Network checks are set per project, not per monitor. You configure them in the **Manage Network Checks** section of [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings): in the left sidebar, select **Conformance**, then the **Settings** tab. ## TLS certificate expiry monitoring APIContext can alert you before your API's TLS certificate expires, giving you time to renew before users are affected. ### Configure expiry alerts 1. Open [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings) and find the **Manage Network Checks** section. 2. Turn on **Enable TLS Certificate checks**. 3. In **Fail when TLS certificates are close to expiry**, choose when the check fails: | Option | The check fails when | |---|---| | **Only fail for expired certificates** | The certificate has expired | | **1 day before certificate expires** | The certificate expires within 1 day | | **7 days before certificate expires** | The certificate expires within 7 days | | **30 days before certificate expires** | The certificate expires within 30 days | A failing check shows on the [Conformance Summary](https://client.apimetrics.io/governance/conformance/summary) under **Network TLS Certificates**. ## CDN allowlist verification If your API is served through a CDN, you can verify that requests are being routed through your expected CDN network and not bypassing it. APIContext supports allowlist verification for 24 CDN providers, including: - Akamai - Amazon CloudFront - Azure Front Door - Cloudflare - Edgio - Fastly - Gcore CDN - And more: see the **Manage Network Checks** section of Conformance Settings for the full list. ### Configure a CDN allowlist check 1. In the **Manage Network Checks** section of Conformance Settings, turn on **Enable Content Delivery checks**. 2. Under **Require calls to be handled by one of the following CDNs**, choose the expected CDN providers. 3. APIContext verifies that the `X-Cache`, `X-CDN`, or server header matches the expected CDN signature. ## Geo-fencing and data sovereignty checks Data sovereignty requirements may require that API traffic stays within specific geographic boundaries. Geo-fencing checks verify three things, each set on its own tab: - **Origin**: calls only pass when they are made from the locations you allow. - **Destination**: calls only pass when they are served by services hosted in the locations you allow. - **Routing**: calls from specific locations only pass when they are routed to services hosted in specific locations. ### Configure geo-fencing 1. In the **Manage Network Checks** section of Conformance Settings, turn on **Enable Geo-fencing and data sovereignty checks**. 2. Open the **Origin**, **Destination**, or **Routing** tab and choose the approved locations. On **Origin**, pick the locations in **Allow calls from**. On **Destination**, pick the locations in **Allow services hosted in**. On **Routing**, pair **Allow calls from** with a destination, so that calls from one location must be served from another. 3. A call that breaks a rule fails the check. If you add rules on more than one tab, a warning appears: "There are rules defined in multiple tabs. This may result in overly permissive conformance checks." Use one tab for each requirement where you can. ## See also - [Test node locations](https://docs.apicontext.com/concepts/test-node-locations.md): available monitoring regions - [Set conditions on a monitor](https://docs.apicontext.com/guides/set-conditions.md) - [Conformance overview](https://docs.apicontext.com/guides/conformance.md) --- # API.expert > Publicly available collections of API monitoring for a variety of API products Source: https://docs.apicontext.com/guides/api-expert ## What is API.expert? API.expert provides data on common APIs that you might use or interact with on a regular basis. This is presented as a set of collections in many key categories including enterprise IT, cloud services, messaging, and open banking. There are at least 160 different providers with over 2000 APIs that we are monitoring with our own keys for you so that you don't have to. A subscription gets you access to a collection which includes: * Historical access to API performance * Reports on API performance * Performance change alerts via email * Real time alerts --- # Catalog > Use the Catalog to list your API's operations next to your monitors, upload an OpenAPI spec, and see how monitors are matched to it. Source: https://docs.apicontext.com/guides/catalog The Catalog function allows you to generate an API Key that will integrate into your application and allow us to view live monitors, as well as all your current monitors, and show these in your Catalog. From here, you can add any of these monitors to your Monitor List and add them to schedules or workflows. Additionally, you can upload your OAS specification to compare to the live traffic for any inconsistencies between the intended architecture and the implemented architecture. ## Configure Catalog ### Set up an API Key The **Catalog** can be found under the **Analytics & Reporting** section in the sidebar. ![Sidebar with Catalog highlighted under the Analytics and Reporting section](https://docs.apicontext.com/img/922a0b3-image.webp) From the Catalog, you can now create your API Key and upload your specifications. To create your API Key, select the **Create an API Key** button. ![Inventory page with the Generate my API key button highlighted](https://docs.apicontext.com/img/98ffcca-image.webp) A popup will appear with your new API Key that you can copy to your clipboard. ![Popup showing the new API key with a copy-to-clipboard button](https://docs.apicontext.com/img/e4f0929-image.webp) If you lose your API Key, it can also be found under the **Advanced** section in **APImetrics API**. From there it can also be deleted. ### Integrate With Your Application APImetrics has multiple observability and egress adaptors for integration with your application. You can view [our observability adaptors](https://docs.apicontext.com/guides/integrations/observability-adaptors.md). ### Optional: Upload OpenAPI Specification To upload your file, select the **Upload my JSON or YAML file** button. ![Add an OpenAPI spec card with the Upload my JSON or YAML file button highlighted](https://docs.apicontext.com/img/24033ba-image.webp) This will open a popup where you can upload your file by selecting the **Choose File** and then the **Upload File** buttons. Note that specification files are limited to 8 MB each. ![Upload an OpenAPI Specification popup highlighting the Choose file and Upload file buttons](https://docs.apicontext.com/img/8a26166-image.webp) After the upload, confirm which base URLs to use for the spec: the specification's dialog lists them under **Servers** ("Please confirm which base URLs you wish to use for this OpenAPI specification"). Only these URLs are used to match monitors, as described in [How monitors are matched to your spec](#how-monitors-are-matched-to-your-spec). ### Checks on an uploaded spec Every uploaded spec is linted. A spec that is not OpenAPI 3.x, or that cannot be parsed, is converted to OpenAPI 3.0 and then linted again. These rules report **errors**: `spec`, `path-declaration-must-exist`, `no-identical-paths`, and `no-unresolved-refs`. Because of `no-unresolved-refs`, every `$ref` must resolve within the uploaded file. These rules report **warnings**: `spec-strict-refs`, `no-undefined-server-variable`, `path-not-include-query`, `path-parameters-defined`, `operation-operationId-unique`, `operation-parameters-unique`, `operation-2xx-response`, `spec-components-invalid-map-name`, `no-server-example.com`, `no-server-trailing-slash`, `no-ambiguous-paths`, and `no-enum-type-mismatch`. A spec with no `openapi` field, such as a Swagger 2.0 file, also gets the warning "API specification file should be OpenAPI 3.x". ## Investigating Results Once you've configured your Catalog, you can then explore your results. From here, you can see the **HTTP Method**, the endpoint **URL**, the **Source** of the call, and how many times it has been called. The **Source** is useful for telling you what monitors are and are not identified in your specs. All of your monitors will be aggregated in the Catalog for easy analysis. From here, you can also add any monitors that are unmonitored by APImetrics by clicking the **Monitor this Endpoint** button. ![Catalog results table listing endpoints by HTTP method, URL, source, and API call count with Monitor this Endpoint buttons](https://docs.apicontext.com/img/a9f4adb-image.webp) ## How monitors are matched to your spec The Catalog lists each operation in your spec once for each confirmed base URL that applies to it, as a method and a full URL (the base URL followed by the operation's path). Server variables in a base URL are expanded: each value of an `enum`, or the `default`. A monitor appears against an operation when the two match: - **Method.** The HTTP methods must be the same. - **Path, compared from the end.** The URLs are compared one path segment at a time, starting from the last segment. Query strings are ignored. - **Path variables match any segment.** A variable in the spec, such as `{petId}` in `/pets/{petId}`, matches any single segment, so a monitor that calls `/pets/123` matches it. - **Hosts must agree when both have one.** If both URLs include a host, the scheme and host must be the same. - **A shorter URL can match the end of a longer one.** For example, an operation whose base URL is the relative path `/v1` matches a monitor that calls `https://api.example.com/v1/pets` for `/v1/pets`. A monitor that matches no operation is still listed, but not as part of your spec. --- # Contacting Us > Ways to reach APIContext: the sales email address, the support portal, and the service status page for incidents and maintenance. Source: https://docs.apicontext.com/guides/contacting-us ## Ways to contact us There are several ways to contact us: * If you want to learn more about our product and plan options, email us at [info@apicontext.com](mailto:info@apicontext.com). * If you need support, [contact support](https://apicontext.com/support). * To check current status of the platform, see the [service status page](https://docs.apicontext.com/status.md). Subscribe to its [RSS feed](https://docs.apicontext.com/status/rss.xml) to be told of new updates: [get notified of incidents and maintenance](https://docs.apicontext.com/guides/get-notified-of-apicontext-status.md) shows how. --- # How to Use Environment Variables for Secure Storage > Instructions on how to securely store and retrieve authentication tokens and other sensitive values using APImetrics' Environment Variables. Source: https://docs.apicontext.com/guides/environment-variables For a reference of all available built-in variables, see [Environment variables](https://docs.apicontext.com/concepts/environment-variables.md). ## 1. Obtain APImetrics API Key To create an APImetrics API Key, follow the instructions on the [APImetrics API Overview](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md) page. ## 2. Add Environment Variables To add your environment variable: 1. Go to Project Settings > [Environment Variables](https://client.apimetrics.io/account-settings/variables/global) (from left-hand navigation bar). 2. Make sure you're in your desired workspace (the default is "global"). 3. Click `+ Add Property`. 4. Give your variable a name and enter some placeholder text in the value field (e.g., "SampleText"). 5. Click `Save`. The page lists all of the variables in a workspace, including workspaces with more than 100. ## 3. Assign a Value to an Environment Variable Use the following API : [Set Environment Variable](https://docs.apicontext.com/reference/api-full/create-environment-variable) to store the value to the Environment Variable created in last step. 1. Fill in the Path Parameters: 1. **Workspace** : (defaults to `global`) 2. **Variable\_name**: (use the same name created in Step 2.4) 2. Pass the new value in the request body using JSON format: ```Text json { "value": "Enter-your-Environment-variable-value" } ``` 3. Select the Authentication settings: 1. Choose Authentication Setting: `APImetrics API` 2. Use the `Token` you created in Step 1.\ > Executing this monitor will update the environment variable with the new value. ## 4. Retrieve an Environment Variable value Use the following API : [Get Environment Variable](https://docs.apicontext.com/reference/api-full/get-environment-variable) to retrieve the value of an Environment Variable. 1. Fill in the Path Parameters: 1. **Workspace** : The name of your workspace (e.g., "global"). 2. **Variable\_name**: The name of the environment variable you want to retrieve. 2. Select the Authentication settings: 1. Choose Authentication Setting: `APImetrics API` 2. Use the `Token` you created in Step 1.\ > This monitor returns the value of the specified environment variable in JSON format. > > The response will have the following structure: > > ```Text JSON > > "workspace_variable": { > > "name": , > > "value": > > } > ``` > **You can automate the secure storage and retrieval of your tokens and other sensitive values by incorporating the [Set Environment Variable** --- # Get notified of APIContext platform status > Follow the APIContext status page and subscribe to its RSS feed in a feed reader, Slack, Microsoft Teams, or email to hear about incidents and maintenance. Source: https://docs.apicontext.com/guides/get-notified-of-apicontext-status Subscribe to the APIContext status feed to hear about incidents, service interruptions, and planned maintenance without checking a page. ## Prerequisites - An RSS reader, or a workspace tool that can follow an RSS feed (Slack, Microsoft Teams, or an RSS-to-email service). ## Steps 1. Open the [service status page](https://docs.apicontext.com/status.md). Under **Recent updates**, it lists incident reports, service updates, and maintenance notices. 2. Copy the feed address: `https://docs.apicontext.com/status/rss.xml` ([open the feed](pathname:///status/rss.xml)). 3. Add the feed address to the tool you want notices in: - **RSS reader:** add it as a new feed or subscription. - **Slack:** install Slack's RSS app in your workspace, then subscribe a channel to the feed address. - **Microsoft Teams:** add an RSS connector or workflow to a channel and give it the feed address. - **Email:** give the feed address to an RSS-to-email service. Each tool's own help explains where to paste a feed address. ## What a notice contains Each item in the feed has a title (for example, "Service interruption - monitoring queue"), the date it was posted, a short summary, and a link to the full notice on the status page. The status page and its feed are the only official sources of APIContext service status. To report a problem you see in your own monitors, [contact support](https://apicontext.com/support). ## Next steps - [Contacting us](https://docs.apicontext.com/guides/contacting-us.md): sales, support, and service status. - [Setting alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md): get notified when your own monitors fail. --- # Organization (Orgs, Collections, Projects & APIs) > How APIContext organizes your work: a collection is a group of projects, a project is a group of APIs, and an organization controls collections. Source: https://docs.apicontext.com/guides/project-navigation ## Basics APImetrics organizes APIs into projects and collections, where a collection is a group of projects, and project is a group of APIs. Think of them like folders. An organization can control multiple collections and a user can be a member of multiple organizations, collections, and projects. [APImetrics Project Home](https://www.youtube.com/watch?v=L021tMaNwng) ## Key Concepts > **What is a user?** > > An individual user account is a user - this will usually be associated with a project but can also be a member of multiple projects, organizations, and more. > **What is a project?** > > A project is a collection of monitors. A project can have different members who can edit the project or view the results. > **What is a collection?** > > A collection is a group of projects or provider APIs from API.expert. > **What is an organization?** > > An organization can be a business or entity that owns a collection of different collections. Users can be members of different organizations. --- # Understanding the Results > See what APIContext stores for each monitor result: the timing breakdown, the location, the HTTP code, the pass, fail, or warning status, and the response. Source: https://docs.apicontext.com/guides/view-results ## Key Concepts APImetrics stores the results of monitors. For each result, the following information is stored: * Detailed call breakdown (Connect Time, DNS Lookup, Processing Time, Total Time) * Location the call was made from * HTTP code returned * Pass, Fail, or Warning if conditions have been set for the call * Response header and body Running a call from the Call Edit screen will take you to the result of that call. All results are stored by monitor. You can also search and view results. For how long results and response bodies are kept, see [Limits](https://docs.apicontext.com/reference/limits.md). ## Results View ![Call Results view showing a list of PASS results for GET /get across multiple global locations, with HTTP 200 status and latency per run](https://docs.apicontext.com/img/ba5b22e-results_view.webp "Call Results — Monitor Results table") 1. The call result summary 2. The reason the call was made - this could be a manual call, a scheduled event or another trigger - you can trigger events inside APImetrics to make calls if you need to 3. The logs for the call showing the setup and configuration 4. Call duration information broken down by network and server side portions 5. The request made 6. The response we got back 7. If there was a body we'll show the body too 8. The initial conditions and internal variables set - each monitor in APImetrics has a unique set of identifiers 9. Any variables set in the monitor > **Tip** > > The call duration breakdown (DNS, TCP connect, TLS handshake, processing, transfer) feeds into APIContext's [network monitoring](https://apicontext.com/features/network-monitoring), which isolates whether performance issues originate at the network, CDN, or application layer. --- # Device Code Authorization flow > To obtain Access tokens for authenticating to API v3 (/api/3/) APImetrics Endpoints, follow these steps: Source: https://docs.apicontext.com/guides/device-code-auth ## 1. Obtain a Device Code * Make a **POST** request to the `/oauth/device/code`endpoint, providing your `Client_id`, `Scope`, and `audience` parameters as shown below. * URL: `https://auth.apimetrics.io/oauth/device/code` * Headers: * Content-Type : `application/x-www-form-urlencoded` * Body Parameters: * client\_id : \[string] * scope : \[array] * audience: `https://client.apimetrics.io` * The Response will contain a `Device code` and a `Verification URI Complete`. > **Check with your organization Admin for your Organization's `Client Id`** ## 2. Redirect the User * Direct the user to the `verification_uri_complete` link. ## 3. Obtain User's Consent * The user will be prompted to grant the application permission to access their data. ## 4. Exchange Device Code for Access Token * Make a POST request to `/oauth/token`endpoint, providing the `Device code` and `Client Id` parameters as shown below: * URL: `https://auth.apimetrics.io/oauth/token` * Headers: * Content-Type : `application/x-www-form-urlencoded` * Body Parameters: * grant\_type : `urn:ietf:params:oauth:grant-type:device_code` * device\_code : \[string] * client\_id : \[string] * The Response contains an `Access Token` and an `ID Token` > **Once you have an Access Token, you can use it to authenticate your API v3 requests by including it in the Authorization header:** > > > **Authorization: Bearer\** --- # Run a monitor on demand > Run a monitor on demand using Run Now or a one-time schedule a location from the picker OR scheduling the call to run Source: https://docs.apicontext.com/guides/schedule-monitors ## Key Concepts monitors and Workflows can be run individually or automated by a schedule to run on an ongoing basis. > **Why schedule your calls?** > > Continuous monitoring at a reasonable frequency allows us to generate meaningful metrics on your API performance and warn you when things go wrong. > **What is a schedule?** > > A schedule lets you run a monitor or workflow on an automated recurring basis from a remote location. The location is typically one of the more than 60 cloud location around the world that APImetrics provides, but it can also be a special location supported by APImetrics over a mobile connection or an internal location if you have installed the APImetrics software agent on your own hardware. > > You can create and edit schedules so that you can exercise your APIs at exactly the frequency you need from the locations that matter to your users. You can also use schedules to halt calls temporarily for instance when APIs are taken down for maintenance. ## Making a 'one-off' call Open a monitor's **Edit** view and click **Run Monitor Now** to run it immediately from our default external location. Use the dropdown arrow next to the button to pick a specific location instead. The result appears inline as soon as the call completes, showing the pass/fail verdict, HTTP status, latency, and the full request and response so you can inspect headers and body without leaving the page. ![Monitor Edit view showing the Run Monitor Now button and an inline Passed HTTP 200 result](https://docs.apicontext.com/img/53bbd1b-Run_API_Call.webp "Run Monitor Now — inline result") ## Automating Monitors (Scheduling) APIs can be scheduled to run automatically from any of our 125+ locations around the world and the cloud. We handle distribution of the calls. > **Suggested Frequency** > > We normally recommend a frequency of one call, per location, every 10-15 minutes i.e. 4-6 times per hour. > **Gateway Rate Limiting WARNING** > > Even though you might have a gateway rated to thousands of calls per minute, we have seen behavior where if 2 or more calls arrive within a few milliseconds of each other, the calls will be rate-limited on the assumption that the monitors will exceed the limit. In a schedule, the calls from each location are offset from one another to avoid this situation. Click **Schedules** in the left-hand menu to open the Schedules page. Each schedule card shows its region coverage, frequency, monitors per day, and how many monitors are currently assigned to it. A **Default Schedule** (worldwide, every 5 minutes) is created for every new project. ![Schedules page showing the Default Schedule (Worldwide, 12/hr) and Eu-Schedule (EU, 6/hr)](https://docs.apicontext.com/img/e104962-Scheduler.webp "Schedules page") Edit a schedule by clicking its **Edit** button. You can change the region set to a specific continent, cloud provider (such as Amazon AWS or Azure), or any combination of individual locations. ![Edit Schedule dialog with the Regions dropdown open showing continents and cloud providers like Amazon AWS and Microsoft Azure](https://docs.apicontext.com/img/e36e2e3-demo_schedule_regions.webp) ## Frequency of Calls Change frequency of calls from the drop-down - the scheduler will automatically randomly assign a location but over a period of time, all agents in a group should be used roughly an equal number of times. ![Edit Schedule dialog with the Frequency dropdown open listing call intervals from once per minute to once every 6 minutes](https://docs.apicontext.com/img/a53a6ce-demo_schedule.webp) ## Downtime If you need to suspend calling for routine maintenance, or a period where you don't need monitoring coverage, you can schedule downtime from the scheduling menu. ![Schedule Downtime dialog with From and Until date-time fields, timezone selector, and Repeat Daily and Weekly toggles](https://docs.apicontext.com/img/7e3e05e-downtime.webp) You can compare and contrast your schedules on the schedules page. For a schedule that is in use, you can see how many a day the schedule will invoke a monitor. You can delete a schedule with the Delete button. Clicking on the Schedule All APIs button for a schedule will schedule all your monitors with that schedule. ## High-frequency monitoring Standard schedules run monitors at intervals of 1 minute or longer. For latency-sensitive services where sub-minute coverage matters, **high-frequency monitoring** supports intervals as short as **1 second**. High-frequency monitoring is available on **CONTRACT tier** accounts only and requires the `feature_highfreq` entitlement to be enabled on your account. Contact your account manager or [sales](mailto:info@apicontext.com) to enable it. See [plan availability and pricing](https://apicontext.com/pricing). ### Available intervals | Interval range | Availability | |---|---| | 1 second – 59 seconds | Contract tier (`feature_highfreq` required) | | 1 minute – 24 hours | All tiers | To set a sub-minute interval, select it from the frequency picker when creating or editing a schedule. If the option is not visible, the `feature_highfreq` entitlement is not enabled on your account. > **Note** > > High-frequency monitors consume quota at a proportionally higher rate. A monitor running every 5 seconds uses 12× the quota of a monitor running every minute. Review your monthly run quota before enabling high-frequency schedules. --- # Set Up Ongoing Observations > A one-off API call doesn't tell you very much about an API or the behavior of it - with 'schedules' you can run automatically from anywhere in the public cloud. Source: https://docs.apicontext.com/guides/ongoing-observations ## Key Concepts monitors and Workflows can be run individually or automated by a schedule to run on an ongoing basis. > **Why schedule your calls?** > > Continuous observation at a reasonable frequency allows us to generate meaningful data on your API performance and warn you when things go wrong. We can typically give you up to 30 minutes more warning than other services and we will pick up technical problems often missed by your gateway or other products. > > Additionally, we can check on the overall quality of your APIs and let you understand how and where things could be improved or spot different regional or cloud-specific problems. > **What is a schedule?** > > A schedule lets you run a monitor or workflow on an automated recurring basis from a remote location. The location is typically one of the more than 60 cloud location around the world that APImetrics provides, but it can also be a special location supported by APImetrics over a mobile connection or an internal location if you have installed the APImetrics software agent on your own hardware. > > You can create and edit schedules so that you can exercise your APIs at exactly the frequency you need from the locations that matter to your users. You can also use schedules to halt calls temporarily for instance when APIs are taken down for maintenance. ## Scheduling your observations APIs can be scheduled to run automatically from any of our 125+ locations around the world and the cloud. We handle distribution of the calls. > **Suggested Frequency** > > We normally recommend a frequency about 10 calls an hour, once every 5 minutes. The more data the more accurate our quality scores. > **Gateway Rate Limiting WARNING** > > Even though you might have a gateway rated to thousands of calls per minute, we have seen behavior where if 2 or more calls arrive within a few milliseconds of each other, the calls will be rate-limited on the assumption that the monitors will exceed the limit. In a schedule, the calls from each location are offset from one another to avoid this situation. If you click on the Schedules item on the left-hand menu, you will be taken to the Schedules page. The default Schedule is predefined. ![APImetrics Schedules page listing the Default Schedule and Eu-Schedule with frequency and monitors per day](https://docs.apicontext.com/img/e104962-Scheduler.webp) Edit the schedule by clicking on the Edit button. You can choose to replace Worldwide with all the locations in a particular region such as Europe or all the locations provided by a certain cloud service provider such as Amazon AWS. ![Edit Schedule dialog with the Regions dropdown open showing continents and cloud providers like Amazon AWS and Microsoft Azure](https://docs.apicontext.com/img/e36e2e3-demo_schedule_regions.webp) ## Frequency of Calls Change frequency of calls from the drop-down - the scheduler will automatically randomly assign a location but over a period of time, all agents in a group should be used roughly an equal number of times. ![Edit Schedule dialog with the Frequency dropdown open listing call intervals from once per minute to once every 6 minutes](https://docs.apicontext.com/img/a53a6ce-demo_schedule.webp) ## Downtime If you need to suspend calling for routine maintenance, or a period where you don't need monitoring coverage, you can schedule downtime from the scheduling menu. ![Schedule Downtime dialog with From and Until date-time fields, timezone selector, and Repeat Daily and Weekly toggles](https://docs.apicontext.com/img/7e3e05e-downtime.webp) You can compare and contrast your schedules on the schedules page. For a schedule that is in use, you can see how many a day the schedule will invoke a monitor. You can delete a schedule with the Delete button. Clicking on the Schedule All APIs button for a schedule will schedule all your monitors with that schedule. --- # Setting Assertions and Conditions > How to set up conditions and assertions on an API endpoint, with practical examples, such as checking a response body for a string. Source: https://docs.apicontext.com/guides/set-conditions **We make it simple to monitor API behavior and catch issues fast using conditions and assertions. This guide shows how to use them and includes practical examples for all experience levels.** ## What are Conditions & Assertions? For what conditions and assertions are and how they differ, see [Conditions and Assertions](https://docs.apicontext.com/concepts/conditions-and-assertions.md). ## How to Set Up Conditions & Assertions > **Note** > > For conditions that apply to every monitor in the project, use **Project Conditions: HTTP**, **Project Conditions: Header**, and **Project Conditions: Latency** in the sidebar ([HTTP](https://client.apimetrics.io/assertions/http), [Header](https://client.apimetrics.io/assertions/headers), [Latency](https://client.apimetrics.io/assertions/latency)). 1. **Edit Your Monitor** * Go to [Monitors](https://client.apimetrics.io/tests/) and open the monitor you want to add checks to. * Open the **Edit** tab and scroll to the **Assertions** section. It has parts for HTTP Status Code, Response Size (bytes), Headers, Response Body, and Timing. 2. **Add a Condition/Assertion** * In the part you want (for example **Response Body**), click **Add assertion...**. * Choose what you want to check: status code, header, response body, `_raw` response, or response size. 3. **Define What to Match** * Pick a check type (equals, contains, less than, etc). * Enter what you expect to see (a number, keyword, or value). 4. **Save & Test** * Save your monitor settings. * Test the call to make sure your assertions behave as intended. *** ## Common & Advanced Scenarios | Scenario | How to Assert | Example Value | Tip | | ------------------------------- | ---------------------------------------------------------- | ------------------ | ----------------------------------------- | | Response status must be 200 | `Status Code equals 200` | 200 | Override for non-standard codes if needed | | Header is correct | `Header: Content-Type equals application/json` | application/json | Use for security or format checks | | Body contains value | `JSON path: user.id equals 5` or `Body contains 'success'` | 5 or 'success' | Good for key data fields | | Full response is empty | `_raw equals ""` | "" | Checks for empty body directly | | Body matches exactly | `_raw equals '{"status":"ok"}'` | '\{"status":"ok"}' | Use for exact response matching | | Body contains keyword | `_raw contains 'activated'` | 'activated' | Use for substring search | | Response is empty (bytes = 0) | `Response Size (bytes) equals 0` | 0 | Reliable for fully empty responses | | Response size under a threshold | `Response Size (bytes) lessThan 100` | 100 | Catch bloats or missing data | | Complex validation | Use `_raw` or custom regex | None | Use when other checks aren't enough | *** ## \_raw Path & Response Size: Best Practices * The `_raw` path lets you check the entire, raw response exactly as received, great for custom formats, binary data, or advanced cases. * *Example: Check if the raw response is empty:* ```json { "assert": {"path": "_raw", "equals": ""} } ``` * *Example: Look for a keyword in the response:* ```json { "assert": {"path": "_raw", "contains": "success"} } ``` * `Response Size (bytes)` helps catch empty or unexpectedly large responses regardless of how they're formatted. * *Example: Assert the response is empty (0 bytes):* ```json { "assert": {"path": "Response Size (bytes)", "equals": 0} } ``` * *Example: Ensure response is not too big:* ```json { "assert": {"path": "Response Size (bytes)", "lessThan": 100} } ``` *** ## Example Scenario: Override default HTTP codes > **Scenario** > > You want to validate that a call cannot succeed from a particular geography or a call with an OAuth scope of a particular kind always fails. In these scenario, the expected behavior should fail, and a Pass indicates a conformance problem. For this example, let's override the default settings to set a HTTP 500 code as a pass and, therefore, a 200 code becomes a fail. Here are the relevant settings: ![Conditions tab settings overriding HTTP status code defaults so a 500 is treated as a pass](https://docs.apicontext.com/img/e89366f-Screenshot_2024-02-20_at_14.24.57.webp) ## Check a Response Body for a Specific String You can examine the returned response body for a variable. For instance, if you are expecting the response body to have an access token, you can set a condition for the monitor to return an error if there is none. ![Conditions tab configuring a response body check that returns an error when a string is missing](https://docs.apicontext.com/img/61f474f-Screenshot_2024-02-20_at_14.34.32.webp) ## Set an Alert based on a timing issue You can set an alert depending on the length of the call or a component of the call. For instance, you can set the response type to Passed but slow if the Total Latency is greater than 1000 ms. ![Timing condition setting a result to passed but slow when total latency exceeds 1000 ms](https://docs.apicontext.com/img/b711453-Screenshot_2024-02-20_at_14.35.52.webp) ## Recommendations & Tips * Start with simple assertions (status codes, headers), then add deeper content checks as your needs grow. * Use the `_raw` path for non-standard responses or when you need total control over matching. * Add response size checks as a safety net against payload changes or API errors. * Update assertions as your API evolves. * Check test results regularly and adjust your checks for new endpoints or behaviors. --- # Add Private Nodes > Deploy private nodes inside your own infrastructure to monitor applications that are not available to the public internet. Source: https://docs.apicontext.com/guides/add-private-nodes APIContext has remote nodes at [125+ locations worldwide](https://apicontext.com/features/api-monitoring), but these are only suitable for accessing publicly available services. To use the platform with services that are not reachable from the public internet, you can deploy [private nodes](https://apicontext.com/features/private-nodes) in your own infrastructure. Private nodes only require outward access to the internet: no inbound routing is needed. All node types (API, Browser, MCP) are deployed in the same way via Docker, with only minor configuration differences. ## Create Nodes To have a node generated for you, make a request via our [support channel](http://apicontext.com/support) for private nodes to be created. For each node we need to know: * The type of node (API, Browser or MCP) * A human-readable Display Name * (Optional) The continent, country, and city of deployment. We will infer these by IP-address geolocation if not provided. * What hardware you will install the node on. _Note that Docker images are built for the AMD64 (x86-64) platform only at present. We have experimental support for ARM64 (e.g. AWS Graviton, Apple Silicon) so please let us know if this is of interest._ For each node requested, we will send you a zip file containing everything needed to deploy your node: * A `docker-compose.yml` file / * An `.env` file containing your node’s specific configuration. _Note that this data is private to your node and must not be reused._ * A `google-application-credentials.json file which gives your node permission to upload data to APIContext storage buckets in Google Cloud ## Deploying in Docker Compose 1. Extract the zip file contents to an empty directory 2. Run `docker compose up` ## Response bodies A private node uploads large response bodies to cloud storage. If the node has no cloud storage credentials, it stores text bodies of up to 32,000 bytes and cuts longer ones at that size, ending them with `<< TRUNCATED >>` and a "Content truncated" message. Binary bodies are not stored. The threshold is set by the node's `APIMETRICS_CONTENT_SIZE_THRESHOLD` setting. See [Limits](https://docs.apicontext.com/reference/limits.md). ## Other Deployment Options The docker container can be run in any container environment such as Google Cloud Run, AWS Elastic Container Service or Azure Application Containers, provided that the settings in `.env` are supplied as environment variables at runtime, and the `google-application-credentials.json` file is mapped to `/app/google-application-credentials.json` in the container filesystem. Using Your Private Nodes Schedule monitors on your node by selecting “Manual Selection” for the Node Selection option, and adding your node from the drop-down list. ![Edit Schedule dialog with Manual Selection adding APIContext Private Node as an individual node](https://docs.apicontext.com/img/37b9be9892ece777d7f2fd70efbcbef83df3f780b0d31dbad12d4f1f647f58df-Private_Nodes_1.webp) You can also manually run Monitors and Workflows on your private nodes by selecting from the dropdown menu on the right of the Run Now button. ![Run Monitor Now dropdown listing node locations including APIContext Private Node in the United Kingdom](https://docs.apicontext.com/img/c87a2fe8d99cc32c6cb00edf824faa655abf1f93993872c30d3fb9d9d97d2191-Private_Nodes_2.webp) For workflows, the drop-down only shows locations rather than individual node names as the system has to pick a location with all available node types for the workflow steps. ![Run Workflow Now dropdown listing locations including Glasgow, GB on a private node](https://docs.apicontext.com/img/935f38b39a30c7843a09154a150171e641c4bf55b7a4f2c5741e687863695d16-Private_Nodes_3.webp) --- # FAQs > Answers to frequently asked questions about deleting your data, getting help with your plan, and monitoring locations such as China nodes. Source: https://docs.apicontext.com/guides/faqs ## APImetrics Platform ### Can I delete my data from your database? As a synthetics platform, we do not monitor real user data in our customers' applications. If you would like your platform user data removed, [contact support](https://apicontext.com/support). ## Pricing/Billing ### I need help with my APImetrics plan. If you are having issues with your APImetrics plan, please get in touch with your account manager or email [info@apicontext.com](mailto:info@apicontext.com) and we will be able to resolve the issue. ## Monitoring locations ### How do I get China monitoring nodes? Submit a support request through the [APIContext support page](https://apicontext.com/support). APIContext enables China nodes in your scheduler, and you then configure monitors through the UI, API, or CLI. China nodes are included in every plan at no additional cost. See [China](https://docs.apicontext.com/concepts/test-node-locations.md#china) for the regions. ## Service status ### How do I find out about APIContext incidents and maintenance? Follow the [service status page](https://docs.apicontext.com/status.md), or subscribe to its RSS feed in a feed reader, Slack, Microsoft Teams, or an RSS-to-email service. See [get notified of incidents and maintenance](https://docs.apicontext.com/guides/get-notified-of-apicontext-status.md). ## Contact Us [Contact support](https://apicontext.com/support). --- # Install and set up the CLI > Install the apimetrics CLI, sign in, select a project, and run your first command, with macOS, Windows, and Linux instructions. Source: https://docs.apicontext.com/guides/install-and-set-up-the-cli Install the [APIContext CLI](https://apicontext.com/features/cli) (`apimetrics`), sign in, select a project, and run your first command. The command reference stays on the [CLI overview](https://docs.apicontext.com/cli.md). ## Prerequisites - An APIContext account to sign in with. ## Installation Install the CLI with your platform's package manager, or download a release binary from GitHub. ### macOS (Homebrew) ```bash brew install apimetrics/tap/apimetrics ``` ### Windows (winget) ```powershell winget install APIContext.APImetricsCLI ``` ### Linux and manual installation Binaries are published as GitHub release assets on the [APImetrics CLI releases page](https://github.com/APImetrics/APImetrics-cli/releases). This works on every platform, including macOS and Windows. 1. Download the archive matching your OS and architecture: - macOS: `apimetrics--darwin-amd64.tar.gz` or `apimetrics--darwin-arm64.tar.gz` - Linux: `apimetrics--linux-amd64.tar.gz` or `apimetrics--linux-arm64.tar.gz` - Windows: `apimetrics--windows-amd64.zip` `` has no leading `v`. For release v0.0.2 the files are named `apimetrics-0.0.2-linux-amd64.tar.gz`, and so on. 2. Verify the download against the published `checksums.txt`. 3. Extract the archive and move the `apimetrics` binary somewhere on your `PATH`. ```bash # Example (Linux amd64) - adjust the version and architecture to the release you downloaded sha256sum --check --ignore-missing checksums.txt tar -xzf apimetrics-0.0.2-linux-amd64.tar.gz sudo mv apimetrics /usr/local/bin/apimetrics apimetrics --version ``` `--version` reports the CLI version, the OpenAPI spec version, and when the spec was last checked. ## Authentication Authentication uses OAuth 2.0. You do **not** set an API key in an environment variable, and there is no `api configure` command: sign in with `login` instead. ```bash apimetrics login ``` - The default interactive `login` uses the **OAuth 2.0 authorization-code flow with PKCE** (`code_challenge_method=S256`). It opens your browser to sign in. - For CI and other headless environments, authenticate with a [service account](https://docs.apicontext.com/cli/reference/authentication.md#service-accounts) using `--service-account `: no browser is needed. - Most commands **auto-trigger login** when they need credentials, so running `login` explicitly is rarely required. - `apimetrics logout` clears cached credentials and the active project. See [Authentication](https://docs.apicontext.com/cli/reference/authentication.md) for OAuth details and named profiles (`-p/--rsh-profile`). ## Selecting a project Most commands operate on an active project. Set it once and it is remembered: ```bash # Choose interactively from the projects you can access apimetrics project select # Or set it directly by ID (no prompt) apimetrics project select prj_abc123 # Show the active project apimetrics project show ``` In CI, where there is no prompt, pass `--project-id` (or set `APIMETRICS_PROJECT_ID`) instead. See [Project](https://docs.apicontext.com/cli/reference/project.md) for details. ## Creating a project You can create a new project directly from the CLI using a [generated command](https://docs.apicontext.com/cli/generated-commands.md). To create a personal project owned by you, use `create-account-project`: ```bash apimetrics create-account-project name: "My New Project" ``` A personal project is not added to any organization, even if you belong to one. Organization admins can create projects in an organization. Find the organization ID, then pass it to `create-project-in-org`: ```bash apimetrics list-account-projects -f 'body.organizations.*.{id, name}' apimetrics create-project-in-org name: "My New Project" ``` After creating it, select it as the active project: ```bash apimetrics project select ``` See [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md) for all the ways to create projects, including from the web UI. ## First monitor via the CLI ```bash # 1. Authenticate (or let the next command trigger it for you) apimetrics login # 2. Select (or create) the project to work in apimetrics project select # 3. List your monitors (a generated command from the loaded API description) apimetrics list-monitors -o json # 4. Discover any other command and its flags apimetrics --help apimetrics list-monitors --help ``` ## Next steps - [Generated commands](https://docs.apicontext.com/cli/generated-commands.md): how the CLI turns the OpenAPI description into commands, and how to discover them. - [CLI overview](https://docs.apicontext.com/cli.md): configuration, endpoints, built-in commands, and global flags. - [CLI command reference](https://docs.apicontext.com/cli/reference.md): built-in command groups and global flags. - [Monitor your first API](https://docs.apicontext.com/monitor-your-first-api.md): end-to-end UI tutorial. --- # Add an API Call > API calls are what APImetrics is all about. Our user interface guides through all the steps necessary to get a call up and running Source: https://docs.apicontext.com/guides/add-a-monitor/add-api-call You can make any type of REST or SOAP monitor with APImetrics using the call editor. APIContext supports REST, SOAP, and GraphQL APIs with import from curl, Postman, or OpenAPI. See [API monitoring capabilities](https://apicontext.com/features/api-monitoring) for the full feature set. A monitor is a real request made to an API endpoint by an APImetrics agent. [Monitor Edit tabs overview](https://www.youtube.com/watch?v=6MimhBSnwmE) [Monitor Edit page](https://www.youtube.com/watch?v=_Qg_Nt3i93g) ## Step by Step Walkthrough: Make an Monitor In the sidebar, under **Configure Monitoring**, click [Monitors](https://client.apimetrics.io/tests/), then click **+ Add New API Call**. In the **Create New API Call** panel, fill in the fields. Only the **URL** is required: | Field | Description | |---|---| | **Method** | The HTTP method, for example `GET` or `POST` | | **URL** | The endpoint to call | | **Name** | Optional. If you leave it empty, the monitor is named after the method and URL | | **Query parameters** | Parameter and value pairs to add to the URL | | **Headers** | Header and value pairs to send with the request | | **Auth setting** and **Token** | The [authentication setting](https://docs.apicontext.com/guides/authentication-settings.md) and token the monitor uses. The token list shows the tokens for the selected setting | | **Body** | Shown for `POST`, `PUT`, and `PATCH`. When you pick one of these methods, a `Content-Type: application/json` header is added unless you have already set one | Click **Create and Edit** to create the monitor and open it in the editor, or **Create Monitor** to create it without opening it. The editor has every other setting. In the editor you can change these fields at any time: ![Monitor Edit form showing the Name field, Method selector (GET), URL field, and Save button](https://docs.apicontext.com/img/494a097-call_edit.webp "Monitor Edit — Configuration form") 1. Name Field for the monitor 2. Select the method GET, PUT, POST etc... 3. EDIT the URI 4. Save the call. Clicking on Edit let you edit the details of the calls. When you're ready, click Run for the call to be executed from our default server (Google US Central-1 (Iowa)) or click the dropdown to pick a specific location. The call will then be executed and the results shown. > **"RUN NOW"** > > Runs the monitor from our default server (Google - Iowa, USA) - the dropdown arrow allows you to pick a different location to run from. We will then show the result of the monitor. > **WE MAKE ACTUAL API REQUESTS FROM THE OUTSIDE** > > APImetrics is calling your server just like an end user would. If the call gives an error or the URI cannot be reached from outside you might want to consider internal test tools until you're ready to test. > **Timeouts** > > Note that all monitors have a maximum timeout of 2 minutes. You can adjust this lower in the Advanced tab. However, if an schedule has a frequency of once every 2 minutes or faster, the maximum timeout is **half the frequency**, i.e. for a once every minute schedule, the APIs will timeout after 30 seconds. ## Review the Result Results will be shown immediately. See [View Results](https://docs.apicontext.com/guides/view-results.md) for details. ## Finding your calls or results later If you can't find your call or result, you can always click on the All Results option in the navigation menu or the Monitors option which will show you a list of all the calls you have defined. [Details are here.](https://docs.apicontext.com/guides/view-results.md) ## Handling Authenticated APIs Obviously most APIs need some form of security, this can be as simple as an API\_KEY coded into the URI or as a parameter, or it can be a complex OAuth sequence. APImetrics handles all of the common forms of API security within the product. You can learn more here: [Authentication Settings](https://docs.apicontext.com/guides/authentication-settings.md) ## What the monitor sends A monitor makes the requests you configure and nothing else: it does not fuzz inputs, scan for other endpoints, or try requests you did not set up. If [Retry on failure](https://docs.apicontext.com/concepts/alerts-and-webhooks.md) is on, a retry repeats the same request. What each kind of monitor sends besides your own settings: **API monitors**, including API monitors run as workflow steps, send one request to the URL you give, with these additions: - **`User-Agent`**: `APImetrics/` followed by the HTTP library versions, when the monitor sets no `User-Agent` of its own. The versions change, so match the `APImetrics/` prefix. - **`traceparent`**: a [W3C Trace Context](https://www.w3.org/TR/trace-context/) header, when the monitor sets none. - **`X-APIContext-Agent: true`**: when **Use APIContext Standard Headers** is on, on the monitor's **Advanced** tab. It is on for new monitors. - **`Cookie`**: in a workflow, the cookies that earlier steps sent and received, unless the step sets its own `Cookie` header. - **Standard HTTP headers** the client adds: `Host`, `Accept: */*` when no `Accept` header is set, and `Content-Length` when there is a body. New monitors start with an `Accept: application/json` header, which you can change. New monitors do not follow redirects. If you turn on **Follow redirects**, the monitor also requests the address a redirect points to, as a browser would. **Browser monitors** open the page in a real browser, so the browser also requests whatever the page loads (scripts, images, and the API calls the page makes), as a visitor's browser would. When **Use APIContext Standard Headers** is on, those requests carry `X-APIContext-Agent: true`. **MCP monitors** open an MCP session with your server, then run only the steps you configure, such as listing tools or calling a tool. A tool call runs that tool with the arguments you set, so choose tools that are safe to run on a schedule. Requests carry a `User-Agent` that begins `APImetrics-MCP/` unless the monitor sets its own, and a `traceparent` header when none is set. To allow monitor traffic through a firewall or bot manager, see [Identify and allow-list APIContext monitor traffic](https://docs.apicontext.com/concepts/identifying-monitor-traffic.md). --- # Authenticated API Calls (help I got a 400!) > Why monitors that need authentication return a 400 error, and that APImetrics makes real external calls requiring a bearer token or API key. Source: https://docs.apicontext.com/guides/add-a-monitor/authenticated-api-calls-help-i-got-a-400 A lot of monitors will require some form of security or authentication in order to be valid.\ This usually takes the form of a Bearer Token or similar API Key type authentication to be added to the monitor before you can make it. Without this you are likely to get a 400 error. > **APImetrics Makes Live Calls From Outside In** > > APImetrics is not a tool like Postman where you can make local calls. We make [real, authenticated calls from outside your stack](https://apicontext.com/features/api-monitoring) and you will need to add the correct security. --- # Browser Monitors > Load a page in a real browser on a schedule and capture paint timings, LCP, resource timings, and console errors for each run. Source: https://docs.apicontext.com/guides/add-a-monitor/browser-monitors > **Note** > > Browser monitors are available in organization projects. In other projects, the [Monitors](https://client.apimetrics.io/tests/) page has no **Add Browser Test** button; [contact support](https://apicontext.com/support) to turn browser monitors on. A **Browser Monitor** loads your page in a real headless browser instead of a plain HTTP client. This captures what a user would see: how long the page takes to render, how each resource loads, and what errors appear in the console. For an overview of browser monitoring capabilities including visual regression detection and HAR capture, see [Website Monitoring](https://www.apicontext.com/features/website-monitoring) on the platform site. ## When to use Use a browser monitor when you need to: - Measure real-browser load performance (not just raw HTTP response time) - Capture paint timings (FCP and LCP) and time to first byte for measuring against a performance budget - Verify that JavaScript-rendered content appears correctly - Detect console errors or failed sub-resource loads that HTTP monitors miss ## Metrics captured | Metric | Full name | What it measures | |---|---|---| | **FP** | First Paint | Time until the browser first renders anything | | **FCP** | First Contentful Paint | Time until the first text or image renders | | **LCP** | Largest Contentful Paint | Time until the largest visible element renders | | **TTFB** | Time to First Byte | Server response time before content begins | | **Page load** | Page load time | Total time to load the page | | **Resource timings** | Resource Timing entries | Timing, status, and size of each request the page makes | Each result also records console messages and failed requests. Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), and First Input Delay (FID) are not collected. ## Setup ### Step 1: Create a browser monitor 1. In the sidebar, under **Configure Monitoring**, click [Monitors](https://client.apimetrics.io/tests/). 2. Click **Add Browser Test**. 3. In the **Create Browser Test** panel, enter the **URL** to load and a **Name**. 4. Click **Create and Edit** to create the monitor and open it, so you can configure it in the next step. **Create Monitor** creates it without opening it. ### Step 2: Configure the monitor On the monitor's **Edit** tab, under **Browser Test Configuration**: | Field | Description | |---|---| | **Name** | The name of the monitor | | **URL** | The page to load (must be publicly reachable from APIContext nodes) | On the monitor's **Advanced** tab: | Field | Description | |---|---| | **User Agent** | A custom user agent string. Leave it blank to use the browser's own user agent. | | **Maximum timeout** | The longest the run may take, in seconds, before the result is a connection error. The limit is 120 seconds, and a run never gets more than half the interval of the schedule it runs on. | ### Step 3: Set conditions Under **Conditions** on the **Edit** tab, **HTTP Status Code** conditions apply to the main page load. These checks are always made: - 200 to 299: Passed - 400 to 499: Warning - 500 or higher: Error Click **Add Condition...** to add your own status code conditions. ### Step 4: Add to a schedule Add the monitor to a [schedule](https://docs.apicontext.com/guides/schedule-monitors.md). Browser monitors are typically run less frequently than HTTP monitors, every 15–60 minutes is common. ## What the monitor sends A monitor makes the requests you configure and nothing else: it does not fuzz inputs, scan for other endpoints, or try requests you did not set up. If [Retry on failure](https://docs.apicontext.com/concepts/alerts-and-webhooks.md) is on, a retry repeats the same request. What each kind of monitor sends besides your own settings: **API monitors**, including API monitors run as workflow steps, send one request to the URL you give, with these additions: - **`User-Agent`**: `APImetrics/` followed by the HTTP library versions, when the monitor sets no `User-Agent` of its own. The versions change, so match the `APImetrics/` prefix. - **`traceparent`**: a [W3C Trace Context](https://www.w3.org/TR/trace-context/) header, when the monitor sets none. - **`X-APIContext-Agent: true`**: when **Use APIContext Standard Headers** is on, on the monitor's **Advanced** tab. It is on for new monitors. - **`Cookie`**: in a workflow, the cookies that earlier steps sent and received, unless the step sets its own `Cookie` header. - **Standard HTTP headers** the client adds: `Host`, `Accept: */*` when no `Accept` header is set, and `Content-Length` when there is a body. New monitors start with an `Accept: application/json` header, which you can change. New monitors do not follow redirects. If you turn on **Follow redirects**, the monitor also requests the address a redirect points to, as a browser would. **Browser monitors** open the page in a real browser, so the browser also requests whatever the page loads (scripts, images, and the API calls the page makes), as a visitor's browser would. When **Use APIContext Standard Headers** is on, those requests carry `X-APIContext-Agent: true`. **MCP monitors** open an MCP session with your server, then run only the steps you configure, such as listing tools or calling a tool. A tool call runs that tool with the arguments you set, so choose tools that are safe to run on a schedule. Requests carry a `User-Agent` that begins `APImetrics-MCP/` unless the monitor sets its own, and a `traceparent` header when none is set. To allow monitor traffic through a firewall or bot manager, see [Identify and allow-list APIContext monitor traffic](https://docs.apicontext.com/concepts/identifying-monitor-traffic.md). ## See also - [Core Web Vitals reference (web.dev)](https://web.dev/vitals/) - [Set conditions on a monitor](https://docs.apicontext.com/guides/set-conditions.md) - [Schedule monitors](https://docs.apicontext.com/guides/schedule-monitors.md) --- # MCP Monitors > Monitor AI agents and tools that expose the Model Context Protocol (MCP): set up, configure assertions, and schedule runs. Source: https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors > **Note** > > MCP monitors are available in organization projects. In other projects, the [Monitors](https://client.apimetrics.io/tests/) page has no **Add MCP Monitor** button; [contact support](https://apicontext.com/support) to turn MCP monitors on. An **MCP Monitor** tests an AI tool or agent that exposes the [Model Context Protocol](https://modelcontextprotocol.io) (MCP). Instead of making a plain HTTP request, APIContext connects to an MCP server, calls one of its tools or resources, and asserts on the response, so you can verify on a schedule that your AI-powered services stay reliable and correct. ## When to use Use an MCP monitor when you want to: - Verify that an MCP server responds to tool calls within acceptable latency bounds - Assert on the structure or content of tool outputs (e.g., a code-generation tool returns valid JSON) - Alert on regressions in AI service availability or response quality ## How it works 1. APIContext connects to your MCP server over the configured transport (HTTP, SSE, or stdio). 2. It issues a tool call or resource request with your configured parameters. 3. The response is evaluated against your assertions (status, schema, content checks). 4. Results are recorded (latency, pass/fail, raw response) and available in the project dashboard. ## Setup ### Step 1: Create an MCP monitor 1. In the sidebar, under **Configure Monitoring**, click [Monitors](https://client.apimetrics.io/tests/). 2. Click **+ Add MCP Monitor**. ### Step 2: Configure the connection The **Create MCP Monitor** panel opens. Fill in the fields: | Field | Description | |---|---| | **URL** | The URL of your MCP server, for example `https://mcp.example.com` | | **Name** | Optional. If you leave it empty, the monitor is named after the URL | | **Timeout (ms)** | Maximum time to wait for a response before marking the result as failed. The default is 30000 (30 seconds) | | **Auth setting** and **Token** | Optional. The [authentication setting](https://docs.apicontext.com/guides/authentication-settings.md) and token the monitor uses to connect to the server | | **MCP Steps Configuration** | The steps to run in one session, in order. Each step has a type: **List Tools**, **Call Tool**, **List Resources**, **List Resource Templates**, **Read Resource**, **List Prompts**, **Get Prompt**, or **Wait for Server Responses**. A **Call Tool** step takes a **Tool Name** | Then click **Create and Edit**. Every step type and its fields are in the [configuration reference](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors/configuration-reference.md). ### Step 3: Set input parameters In a **Call Tool** step, under **Parameters**, provide the tool's input in JSON format. Use APIContext variables (`%%VAR%%`) for values that change between runs. ### Step 4: Add assertions Use the **Assertions** tab to check the response: - **Status**: the tool returned a result (not an error) - **Schema**: the response matches a JSON schema - **Content**: a JSON path value equals, contains, or matches a pattern ### Step 5: Add to a schedule Add the monitor to a [schedule](https://docs.apicontext.com/guides/schedule-monitors.md) to run automatically. ### Result types MCP monitor results distinguish two kinds of error: - **MCP Transport Error**: a problem communicating with the MCP server. - **MCP server returned an error**: the server was reached but returned an error of its own. ## What the monitor sends A monitor makes the requests you configure and nothing else: it does not fuzz inputs, scan for other endpoints, or try requests you did not set up. If [Retry on failure](https://docs.apicontext.com/concepts/alerts-and-webhooks.md) is on, a retry repeats the same request. What each kind of monitor sends besides your own settings: **API monitors**, including API monitors run as workflow steps, send one request to the URL you give, with these additions: - **`User-Agent`**: `APImetrics/` followed by the HTTP library versions, when the monitor sets no `User-Agent` of its own. The versions change, so match the `APImetrics/` prefix. - **`traceparent`**: a [W3C Trace Context](https://www.w3.org/TR/trace-context/) header, when the monitor sets none. - **`X-APIContext-Agent: true`**: when **Use APIContext Standard Headers** is on, on the monitor's **Advanced** tab. It is on for new monitors. - **`Cookie`**: in a workflow, the cookies that earlier steps sent and received, unless the step sets its own `Cookie` header. - **Standard HTTP headers** the client adds: `Host`, `Accept: */*` when no `Accept` header is set, and `Content-Length` when there is a body. New monitors start with an `Accept: application/json` header, which you can change. New monitors do not follow redirects. If you turn on **Follow redirects**, the monitor also requests the address a redirect points to, as a browser would. **Browser monitors** open the page in a real browser, so the browser also requests whatever the page loads (scripts, images, and the API calls the page makes), as a visitor's browser would. When **Use APIContext Standard Headers** is on, those requests carry `X-APIContext-Agent: true`. **MCP monitors** open an MCP session with your server, then run only the steps you configure, such as listing tools or calling a tool. A tool call runs that tool with the arguments you set, so choose tools that are safe to run on a schedule. Requests carry a `User-Agent` that begins `APImetrics-MCP/` unless the monitor sets its own, and a `traceparent` header when none is set. To allow monitor traffic through a firewall or bot manager, see [Identify and allow-list APIContext monitor traffic](https://docs.apicontext.com/concepts/identifying-monitor-traffic.md). ## See also - [MCP monitor configuration reference](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors/configuration-reference.md): the fields, step types, and limits the API and CLI accept - [AI monitoring](https://apicontext.com/features/ai-monitoring) on the APIContext website - [Set conditions on a monitor](https://docs.apicontext.com/guides/set-conditions.md) - [Authentication in a workflow](https://docs.apicontext.com/guides/authentication-settings/authentication-in-a-workflow.md) - [Monitor types overview](https://docs.apicontext.com/concepts/projects-and-collections.md) --- # MCP monitor configuration reference > Every field an MCP monitor accepts through the API and CLI, including the eight step types, their timeouts, and the auth settings and token fields. Source: https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors/configuration-reference > **Note** > > MCP monitors are available in organization projects. In other projects, the [Monitors](https://client.apimetrics.io/tests/) page has no **Add MCP Monitor** button; [contact support](https://apicontext.com/support) to turn MCP monitors on. This page lists the fields of an MCP monitor as the APIContext API and the `apimetrics` CLI define them. To set up a monitor in the portal, see [MCP monitors](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors.md). An MCP monitor runs a list of steps against one MCP server URL in one session. The same fields apply to both operations that write a monitor, and every operation is also a CLI command named for its operation ID, such as `apimetrics create-mcp-monitor`. Run `apimetrics create-mcp-monitor --help` to print the input schema and an example. ## Operations | Operation | Method and path | Reference | |---|---|---| | `list-mcp-monitors` | `GET /api/3/monitors/mcp/` | [List all MCP Monitors for a project](https://docs.apicontext.com/reference/api-full/list-mcp-monitors) | | `create-mcp-monitor` | `POST /api/3/monitors/mcp/` | [Create a new MCP Monitor](https://docs.apicontext.com/reference/api-full/create-mcp-monitor) | | `read-mcp-monitor` | `GET /api/3/monitors/mcp/{monitor_id}` | [Read an MCP Monitor by ID](https://docs.apicontext.com/reference/api-full/read-mcp-monitor) | | `update-mcp-monitor` | `PUT /api/3/monitors/mcp/{monitor_id}` | [Update an existing MCP Monitor](https://docs.apicontext.com/reference/api-full/update-mcp-monitor) | | `patch-mcp-monitor` | `PATCH /api/3/monitors/mcp/{monitor_id}` | [Patch an existing MCP Monitor](https://docs.apicontext.com/reference/api-full/patch-mcp-monitor) | | `delete-mcp-monitor` | `DELETE /api/3/monitors/mcp/{monitor_id}` | [Delete an existing MCP Monitor](https://docs.apicontext.com/reference/api-full/delete-mcp-monitor) | | `query-mcp-monitor-performance` | `POST /api/3/monitors/mcp/{monitor_id}/stats/performance` | [Aggregate performance metrics for an MCP monitor over a window](https://docs.apicontext.com/reference/api-full/query-mcp-monitor-performance) | | `query-mcp-performance` | `POST /api/3/monitors/mcp/stats/performance` | [Aggregate performance metrics across all MCP monitors in the project](https://docs.apicontext.com/reference/api-full/query-mcp-performance) | Every operation accepts an optional `apimetrics-project-id` header that selects the project. ## Monitor fields These fields go in the request body for `create-mcp-monitor` and `update-mcp-monitor`. `patch-mcp-monitor` takes the same fields, and none of them is required. | Field | Type | Required | Default | Description | |---|---|---|---|---| | `name` | string | Yes | none | Display name for the monitor. | | `description` | string or null | No | none | Optional description for the monitor. | | `tags` | array of strings | No | none | Tags to apply to the monitor for grouping or advanced features. | | `workspace` | string | No | `global` | Workspace to assign the monitor to. | | `url` | string | Yes | none | Target URL for the monitor. | | `overall_timeout_ms` | integer | No | `30000` | Session timeout for the monitor, in milliseconds. Accepts 0 to 120000. | | `steps` | array of [steps](#step-fields) | No | none | Steps to execute during the MCP session. When you supply the array, it holds at least one step. | | `auth_id` | string or null | No | none | Auth settings to use with the monitor. | | `token_id` | string or null | No | none | Auth token to use with the monitor. | ### Authentication fields `auth_id` and `token_id` are the only authentication fields in the MCP monitor schema. Each takes the ID of an existing object as a string, or null for none. `auth_id` selects the auth settings for the monitor and `token_id` selects the auth token. For how auth settings and tokens work, see [Authentication model](https://docs.apicontext.com/concepts/authentication-model.md). ## Step fields Each entry in `steps` is an object, and `step_type` selects its type. The schema sets `additionalProperties` to false on every step type, so a step with a field that is not listed here does not match the schema. Every step type has these fields: | Field | Type | Required | Description | |---|---|---|---| | `step_type` | string | No | The step type from the table below. Each schema defaults it to its own type. | | `timeout_ms` | integer | Yes | Step timeout, in milliseconds. Accepts 0 to 120000. | | `wait_ms` | integer | Yes | Time to wait after finishing the step, in milliseconds. Accepts 0 to 120000. | ## Step types | `step_type` | What it does | Additional fields | |---|---|---| | `list_tools` | Lists the tools the server exposes. | None | | `call_tool` | Calls one tool. | `tool_name` (string, required): name of the tool to call. `parameters` (object or null): arguments to provide for the tool call. | | `list_resources` | Lists the resources the server exposes. | None | | `list_resource_templates` | Lists the resource templates the server exposes. | None | | `read_resource` | Reads one resource. | `resource_uri` (string, required): URI of the resource to read. | | `list_prompts` | Lists the prompts the server exposes. | None | | `get_prompt` | Gets one prompt. | `prompt_name` (string, required): name of the prompt to get. `parameters` (object or null): arguments to provide to the prompt template. | | `wait` | Waits. | None | ## Example This body creates a monitor with two steps, the first listing tools and the second calling one tool with an argument. It is the `call_tool` example from the API reference, with a placeholder server URL. ```json { "name": "Echo health check", "tags": [], "workspace": "global", "url": "https://mcp.example.com", "overall_timeout_ms": 60000, "steps": [ { "step_type": "list_tools", "timeout_ms": 10000, "wait_ms": 0 }, { "step_type": "call_tool", "timeout_ms": 15000, "wait_ms": 0, "tool_name": "echo", "parameters": { "message": "ping" } } ] } ``` ## Monitor object `create-mcp-monitor`, `read-mcp-monitor`, `update-mcp-monitor`, and `patch-mcp-monitor` return the monitor as an object with three parts. | Field | Type | Description | |---|---|---| | `id` | string | The monitor ID. | | `meta` | object | `monitor_type` (`mcp`), `name`, `description`, `tags`, `domain` (the domain of the target URL), `created`, `last_update`, `owner`, and `workspace`. | | `setup` | object | `url`, `overall_timeout_ms`, `steps`, `auth_id`, and `token_id`. The step objects are the ones described above. | `list-mcp-monitors` returns a `results` array of these objects. ## Performance queries `query-mcp-monitor-performance` aggregates one monitor's timings over a window, and `query-mcp-performance` does the same across the project's MCP monitors. Both take this request body. | Field | Type | Required | Description | |---|---|---|---| | `from` | string (date-time) | Yes | Window start, as a UTC ISO timestamp, inclusive. | | `to` | string (date-time) | Yes | Window end, as a UTC ISO timestamp, exclusive. | | `interval` | string (ISO 8601 duration) or null | No | Bucket size for time-series grouping, such as `PT1H` or `PT15M`. When omitted, the whole window is one bucket. | | `metrics` | array | No | Metrics to aggregate: `total`, `initialize`, `dns`, `tcp`, `tls`, `network`, `total_no_dns`. Defaults to the monitor type's standard set. | | `measures` | array | No | Statistical measures to return for each metric: `mean`, `p50`, `p90`, `p95`, `p99`. Defaults to all five. | | `group_by` | array | No | Dimensions to group results by: `location`, `interval`, `monitor`. | | `locations` | array of strings | No | Restrict to these location IDs. Empty means all locations. | | `status` | array | No | Restrict to these result categories: `PASS`, `SLOW`, `WARNING`, `FAIL`. Empty means all categories. | | `poor_thresholds` | object | No | A threshold value for each metric, keyed by metric name. When you supply it, the response includes a `poor_count` for each matching metric, counting samples whose value exceeds the threshold. | On the project-wide query, group by `monitor` to get one group per monitor, or by `monitor` and `interval` for a time series per monitor. Without a `monitor` grouping, the result is a single project-wide aggregate. ## Next steps - [MCP monitors](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors.md): set up an MCP monitor in the portal. - [Monitors](https://docs.apicontext.com/concepts/monitors.md): what a monitor is and the three monitor types. - [CLI generated commands](https://docs.apicontext.com/cli/generated-commands.md): how each API operation becomes a command. --- # Multi-part form-data > How to build a multi-part form-data file in the Files section using the helper form, then use it in a monitor to POST encapsulated form data. Source: https://docs.apicontext.com/guides/add-a-monitor/multi-part-form-data If you wish your API to POST multi-part form data, you can create a file that encapsulated the full form data using our helper form. In the sidebar, under **Project Settings**, select **Files** ([open it](https://client.apimetrics.io/files/)), then select **Upload File**. The **File Upload** page has a **Multi-part form builder** section. ![Multi-part form builder with a Part Type and Part Name picker, an Add Part button and a Save multi-part form data button](https://docs.apicontext.com/img/098d995-Screen_Shot_2019-07-02_at_6.13.10_PM.webp) Choose the type of each part you want to add by using the Part Type picker: ![Part Type dropdown open showing the file and text options for the part being added](https://docs.apicontext.com/img/92f8521-Screen_Shot_2019-07-02_at_6.13.17_PM.webp) The text option allows you to pass form data along with a file. Click "Add Part" to add the parts in the section below. Once the parts have been added, add the data you require (either by using Choose file..) or by entering the data: ![Parts section with a text part named data set to variable_data=1, above the Save multi-part form data button](https://docs.apicontext.com/img/1d91f5f-Screen_Shot_2019-07-02_at_6.14.26_PM.webp) Now you are ready to save the file - Click "Save multi-part form data" to save the data. You can then edit a monitor to use this file data. Follow the steps on the [Uploading Files](https://docs.apicontext.com/guides/add-a-monitor/uploading-files.md) page. ![Raw multi-part form-data HTTP request showing form boundaries, a calendar file part, and data fields](https://docs.apicontext.com/img/f0353a4-Screen_Shot_2019-07-02_at_6.41.39_PM.webp) An example multi-part request with textual data that can be displayed --- # Obtain an API call ID > Find a monitor's ID in APIContext: open Monitors, add the ID column with Select Columns, and copy the ID from the list. Source: https://docs.apicontext.com/guides/add-a-monitor 1. **Navigate to Monitors:** In the left-hand navigation bar, under `Configure Monitoring`, click on "[Monitors](https://client.apimetrics.io/tests/)". 2. **Open Column Selection:** At the top-right of the monitors list, click "Select Columns". 3. **Display the ID Column:** From the list of available columns, select the "ID" option. 4. **Copy the ID:** The monitor IDs will now be displayed in a new column. Right-click on the desired ID and select "Copy" to add it to your clipboard. ![Monitors list with Select Columns open and the ID column turned on, below the buttons that add API, browser, and MCP monitors](https://docs.apicontext.com/img/2c678ef33b7caef9909c68bc4bbf20dbce4d75fce8c4d1b808a394efbb1d5cbd-API-Call-ID.webp) --- # Uploading Files > How to upload files in APImetrics and use the File or Binary content type in a monitor to send file data in POST or PUT requests. Source: https://docs.apicontext.com/guides/add-a-monitor/uploading-files ## Key Concepts Instead of posting JSON or similar text-based data, you can use the File Uploads to send more complex data in your API requests. > **Multi-part form data** > > You can choose to upload a file, or to create multi-part from data that encapsulated multiple files ![APImetrics Files page listing an uploaded content file with type, length and last updated, plus an Upload File button](https://docs.apicontext.com/img/f5148d2-Screenshot_2022-12-02_at_11.54.39_AM.webp) > **Maximum file size** > > Each uploaded file is limited to 8 MB. Files over the limit are rejected at upload time. [Contact support](https://apicontext.com/support) if the limit is a problem for your use case. ## Handling File Uploads You can upload files from the Files link in the Advanced section on the left of each APImetrics page. Click on the +Upload File button. This will open a file picker in your browser to upload. If you wish to send Multi-part data, you can build up the data using the form-builder. Upload each file and give the each field a name. This will save the full multi-part message as one file. ![Files link under the Advanced section showing the Upload File button used to add files for monitor requests](https://docs.apicontext.com/img/f86a1ed-Screenshot_2022-12-02_at_11.50.03_AM.webp) ## Using the File in a monitor When editing the monitor, expand the "Body..." section.\ Then select the File / Binary content type, this will expose the file picker: ![Monitor editor Body section with the Content Type set to File / Binary, exposing the file picker](https://docs.apicontext.com/img/a353fbe-Screenshot_2022-12-02_at_11.50.52_AM.webp) Then select the file you wish to use.\ Remember to Click "Save" to store your changes. ![Monitor editor with a file selected for the File / Binary body, ready to Save the changes](https://docs.apicontext.com/img/2a2a074-Screenshot_2022-12-02_at_11.51.04_AM.webp) > **POST and PUT only** > > Note that you must use an HTTP method of POST or PUT to upload content with the request --- # Managing Project-Level Downtimes > Apply downtime windows to one schedule or to all your monitors so calls do not run, and failures are not flagged, during planned maintenance. Source: https://docs.apicontext.com/guides/setting-and-managing-schedules/managing-project-level-downtimes You can apply downtime windows to an individual schedule associated with an individual monitor you're watching or to all your monitors. During the defined downtime window, calls will not run.This is useful if you're planning a maintenance window, and you don't want to flag failed calls during a planned downtime. > **Organization-level downtimes** > > This page provides instructions to manage downtimes on a per-project basis, which is available to customers on Starter, Teams, Pro, and Enterprise tiers. Pro and Enterprise customers also have the ability to manage downtimes for the entire organization. Instructions on managing organization-level downtimes via API are here: [Create Org Downtime](https://docs.apicontext.com/reference/api-full/create-org-downtime) To implement a **Downtime** for your Schedule, select the **Add Downtime** button for the desired Schedule. ![Schedule header row with the Add Downtime button highlighted next to Edit and Delete](https://docs.apicontext.com/img/8836d58-image.webp) This will bring up a popup where you can set the date and time for the start and end of your downtime and the timezone. This downtime can also be set to repeat daily or weekly. > **Downtime is set for your current time, and will adjust for daylight savings automatically** > > If you set or modify your schedule during daylight savings time, it will use the current time, and adjust automatically. Similarly, if you set or modify during standard time, it will also use the current time and adjust throughout the year. > > On the days when daylight savings time starts and ends (in the spring and fall), it is possible that a downtime period could traverse the daylight savings time shift. In this case, the system calculates the total downtime period to be the same as the regular schedule, from the beginning of the downtime period. > > Here's an example: > > Downtime period set for 12:00 AM - 3:00 AM. > > The total downtime period is 3 hours. > > On the day when clocks "spring ahead," the downtime will still be 3 hours, commencing at 12:00 AM standard time, and ending at 4:00 AM daylight savings time. > > On the day when clocks "fall back," the downtime will be also be 3 hours, commencing at 12:00 AM daylight savings time, and ending at 2:00 AM standard time. ![Schedule Downtime popup with From and Until date and time, timezone, and repeat daily or weekly toggles](https://docs.apicontext.com/img/b69543f-Screenshot_2024-02-28_at_13.07.11.webp) Once your done, select the **Save changes** button. ![Schedule Downtime popup with the Save changes button highlighted to confirm the downtime window](https://docs.apicontext.com/img/1698426-image.webp) > **Downtime Schedule auto-adjustments** > > To ensure optimal scheduling during downtime periods, the system automatically adjusts the **start time** of scheduled tasks to align with the nearest scheduled interval. > > Example: For a Schedule configured to run with a frequency of > > **5-Minute Interval:** If a downtime is scheduled between 10:07 AM and 11:07 AM, the system will automatically adjust the start time to 10:05 AM. > > **2-Hour Interval:** If a downtime is scheduled between 2:30 PM and 4:30 PM, the system will automatically adjust the start time to 2:00 PM. > > This adjustment ensures that downtime periods effectively cover all scheduled tasks within the specified timeframe. > **Downtime will apply AFTER the last scheduled call has been executed** > > You might want to schedule some time around the start of your maintenance window - the reason is calls might be scheduled in the queue before the downtime starts and the call might start inside the window. For example, if you have a downtime scheduled to start at 12:00, and a monitoring call also scheduled for 12:00, the call will complete before the downtime begins. ## Suspending Alerts If you would rather leave the calls scheduled, you can turn off the alerts for the period of downtime - this currently has to be done per alert and per project. --- # Managing Schedules > Schedules makes it easy to manage the frequency and nature of the observation calls we make from around the world. Source: https://docs.apicontext.com/guides/setting-and-managing-schedules ## Key Concepts > **What is a schedule?** > > A schedule lets you run a monitor or workflow on an automated recurring basis from a remote location. The location is typically one of [125+ cloud locations](https://apicontext.com/features/api-monitoring) worldwide that APIContext provides, but it can also be a special location supported by APIContext over a mobile connection or an internal location if you have installed a [private node](https://docs.apicontext.com/guides/add-private-nodes.md) on your own hardware. > > You can create and edit schedules so that you can exercise your APIs at exactly the frequency you need from the locations that matter to your users. You can also use schedules to halt calls temporarily for instance when APIs are taken down for maintenance. ## Scheduling Your API > **Suggested Frequency** > > We normally recommend a frequency of one call, per location, every 10-15 minutes i.e. 4-6 times per hour. > **Gateway Rate Limiting WARNING** > > Even though you might have a gateway rated to thousands of calls per minute, we have seen behavior where if 2 or more calls arrive within a few milliseconds of each other, the calls will be rate-limited on the assumption that the monitors will exceed the limit. In a schedule, the calls from each location are offset from one another to avoid this situation. To view your **Schedules**, select the **Schedules** option in the sidebar. ![Sidebar Configure Monitoring menu with the Schedules option highlighted](https://docs.apicontext.com/img/77cfe6d-Schedules_Nav.webp) You can create **Schedules** for your monitors or Workflows and turn on and off different schedules you have created. The default **Schedule** is predefined. ![Schedules page listing each schedule with its regions, frequency, monitors per day, and quota usage](https://docs.apicontext.com/img/d5a04b1-Schedules_List.webp) To create a schedule, select the **New Schedule** button or to edit an existing **Schedule**, select the **Edit** button. ![Schedules page with the New Schedule button and per-schedule Edit buttons highlighted](https://docs.apicontext.com/img/96eb204-New_Edit.webp) A popup will open where you can **name** your schedule, choose the **frequency** it runs. ![Edit Schedule dialog with fields for the schedule name and run frequency](https://docs.apicontext.com/img/a4f69b2-Schedule_Form.webp) You can also choose whether you want it to run **worldwide** or choose from different **continents** or **cloud service providers**. Worldwide does not include China, which is a separate region available on request. See [China](https://docs.apicontext.com/concepts/test-node-locations.md#china). ![Edit Schedule dialog Node Selection dropdown for choosing worldwide, continents, or cloud providers](https://docs.apicontext.com/img/8c090f9-Node_Selection.webp) If you select the **Advanced** option, you can fine-tune even further by selecting specific **locations**, including any [private nodes](https://apicontext.com/features/private-nodes) deployed in your own infrastructure. ![Edit Schedule Node Locations tab listing individual AWS regions to select specific locations](https://docs.apicontext.com/img/091956d-Node_Locations.webp) Finally, you can choose what **retry on failure method** you would like if any and if you are using the **Postman Monitoring** feature, you can choose this scheduling here. Once you're happy with your schedule, select the **Save changes** button and your schedule will be created. > **Saved schedules will be queued to start running automatically** > > Once you save your schedule, the system will automatically load-balance capacity and start running your schedule. It may take up to 15 minutes for your schedule to be load balanced and launched. You can delete a **Schedule** with the Delete button. ![Schedules page with the per-schedule Delete button highlighted alongside Add Downtime and Edit](https://docs.apicontext.com/img/8fa0bad-Delete.webp) > **Timeouts** > > Note that all monitors have a maximum timeout of 2 minutes. However, if an schedule has a frequency of once every 2 minutes or faster, the maximum timeout is **half the frequency**, i.e. for a once every minute schedule, the APIs will timeout after 30 seconds. --- # The Basics > Adding authentication to API calls with our authentication and token manager Source: https://docs.apicontext.com/guides/authentication-settings/basics-of-authentication-settings-and-tokens ## The Basics Within APImetrics you can set up a type of authentication to be used with a call, or set of calls - that will be something like an API Key, OAuth and so on, and then, within the type of authentication you can set the TOKEN to be used. ## Authentication Settings In the sidebar, under **Configure Monitoring**, select **Monitor Authentication** ([open it](https://client.apimetrics.io/auth/)). The **Auth Settings** page lists the auth settings in the project by name, tags, auth type, and last update. ![Auth Settings page listing auth settings by name, tags, auth type, and last updated, with an Add new Auth Setting button](https://docs.apicontext.com/img/4ce158d-auth.webp) Select **Add new Auth Setting** to open the **Create Authentication** panel. ## Creating an Authentication Configuration There are four things to consider when creating a new authentication configuration. ![Create Authentication panel for an API key setting with Name, Endpoint Domain, Authentication Type, Refresh Token Workflow, SSL Certificate, Documentation, and Custom Variables fields](https://docs.apicontext.com/img/f10783a-auth_2.webp) 1. **Endpoint Domain**: the domain the auth calls, as a plain domain name such as `api.example.com` (no slashes). This helps with identification and with automating parts of the auth process. 2. **Authentication Type**: API key in request / Manual Setup, OAuth 2, Basic Auth, OAuth 1, OAuth 2 + JSON Web Signature (JWS), or OAuth 2 + JSON Web Token (JWT). The OAuth types add fields for the provider's Authorize URL, Get Token URL, Client ID, and Client Secret. 3. **Refresh Token Workflow** and **SSL Certificate**: shown for API key in request / Manual Setup. The SSL Certificate field adds [mutual TLS](https://docs.apicontext.com/guides/advanced-authentication/mutual-tls.md). 4. **Advanced**: **Custom Variables**, a JSON dictionary of values to use with this auth setting. Keys are converted to uppercase. To run a workflow or monitor when a provider redirects back after sign-in, use the [callback handler](https://docs.apicontext.com/guides/advanced-authentication/custom-authentication.md#callback-handler). ## Tokens Tokens are set and configured for an Authentication Setting - i.e. you could have multiple OAUTH tokens for the same domain with each one using a different scope.\ In the example, we're going to create a manual token with an API Key for use in the call string. Select an auth setting in the list to open it. The page shows its name, domain, and auth type, and a table of its tokens. ![Auth setting detail page showing its name, domain, and auth type, an empty tokens table, and the Edit, Add New Token, and Delete buttons](https://docs.apicontext.com/img/0d564b9-auth_3_token.webp) Select **Add New Token**, give the token a name, and then set the headers or parameters it adds to the call. ![Add New Token panel sending an API key as a parameter named apikey with the value YOUR_API_KEY, ready to save](https://docs.apicontext.com/img/2064d0a-auth_4_token.webp) ## Using the AUTH settings and TOKEN Once you have saved the auth setting and token, open your monitor's editor. Choose them under **Settings** and **Token** in the **Authentication** section. --- # Upload a Signing Certificate > Use this guide to securely upload a signing certificate and automatically compute its Key ID. Source: https://docs.apicontext.com/guides/authentication-settings/certificates/upload-a-signing-certificate ## Follow this step-by-step guide below to upload a signing certificate and compute its Key ID: 1. Go to your Organization Settings -> Certificates page ![Organization Certificates](https://docs.apicontext.com/img/89ac66dbc6ee4469629b9b48bb8e20a69fa6c3cbe52d8074f4dcebe705d2613a-Organization_Certificates.webp) 2. Click "Add Certificate". 3. When the Certificate Details Form opens, enter a **Name** for your Certificate. 4. Under "Intended Use", select one of the following: * "RSA Signing (PSS)" - for PS256 signing * "RSA Signing (PKCS#1)" - for RS256 signing (older, less commonly used) ![Certificate Details Form](https://docs.apicontext.com/img/2d2501ca82c189b2cdee146bc289a78a81305e6060213150e0643cc7634f122e-Certificate-Form.webp) 5. Choose the Key ID calculation method. This determines how the certificate is identified in the Signing Helper API. Select one of the following: * “Enter Key ID manually” - if you already have the Key ID. * “UK Open Banking [RFC7638 - SHA1]” - for UK Open banking projects. * “RFC7638 - SHA256” - for all other use cases. ![Key-Id Calculation Method](https://docs.apicontext.com/img/48a522808f8a52c07553d964590bc9cb0ac71c68a1a1aaf730a36c48f8345cbd-Certificates-KeyID-Method.webp) 6. Paste the Certificate, Private Key, and optional Password into the respective fields. ![Upload Certificate](https://docs.apicontext.com/img/544d566a8c6e6fa054fbb4bf292f37f140922f9942210d29f2ce49e6ab553bbb-Add_Certificate.webp) 7. Click "Add" to upload the Certificate. Once uploaded, the new certificate appears in the Certificates table. You can copy its Key ID from there for use in your integration. --- # Setting Up API Key Based Authentication > Set up a shared API key authentication: create it in Monitor Authentication, add a token, and use the auth setting in a monitor. Source: https://docs.apicontext.com/guides/authentication-settings/creating-an-authentication ## Step 1 - Create an authentication setup In the sidebar, under **Configure Monitoring**, select **Monitor Authentication** ([open it](https://client.apimetrics.io/auth/)), then select **Add new Auth Setting**. ![Auth Settings page with the Add new Auth Setting button highlighted to start creating an authentication](https://docs.apicontext.com/img/1645b0f-Authentication_Settings.webp) In the **Create Authentication** panel, choose the **Authentication Type** and complete its fields. For an API key, choose **API key in request / Manual Setup** and enter a name and the endpoint domain. An OAuth flow also needs the provider's URLs and your Client ID and Client Secret. Select **Save**. ![Saved auth setting with API key in request / Manual Setup as its auth type, no tokens yet, and an Add New Token button](https://docs.apicontext.com/img/bda56d3-Step_2_-_no_token.webp) ## Create a Token Select **Add New Token**. For the simple API key example, choose where the monitor sends the key: add it as a header or as a parameter, then select **Save**. ![Add New Token panel with Headers and Parameters key-value rows, sending the API key as a parameter named apikey](https://docs.apicontext.com/img/c959c94-Create_Token.webp) ## Use the Auth Settings in a call When you set up or edit a monitor, choose your auth setting under **Settings** and the token under **Token** in the **Authentication** section of the editor. ![Monitor editor with the Authentication section highlighted, showing an auth setting and token selected for the monitor](https://docs.apicontext.com/img/e02d934-use_api_key.webp) --- # Fundamentals of OAuth in APImetrics > Key concepts for OAuth in APIContext: what you need from the authenticating service, and the steps from creating the app to adding auth to a monitor. Source: https://docs.apicontext.com/guides/authentication-settings/fundamentals-of-oauth > **Tip** > > Setting up OAuth authentication is the first step toward [runtime API security monitoring](https://apicontext.com/features/api-security). APIContext validates that OAuth flows, JWT tokens, and FAPI compliance work correctly in production, not just at design time. OAuth is a mutli-step authentication system that will involve a user authenticating against an external application, where a dedicated 'Application' has been created.\ The power of the integrated APImetrics OAuth handler is we can then manage scopes, refresh tokens and other features entirely separately to the logic of making monitors. This makes the upkeep and maintenance of your collections easier. > **You will need...** > > * Your app being set up at the receiving service > * A ClientID and Secret > * The URLs used by the authenticating service ## 1. Create or Access the App on the authenticating service In the settings for the application you will need to verify that an application is ready for the API to call, and has been set up. You will then need to note the following: * ClientID * ClientSecret * The authorize URL * The Get Token URL ## 2. Set Call Back URL This is essential for us to handle the Token returned by the system and handle the Token. ```http https://client.apimetrics.io/tokens/callback/ ``` The CallBack process will also allow you to call another workflow or sequence to simplify saving tokens. ## 3. Create an OAuth Authentication Setup in APImetrics You will need to put in the ClientID, Secret, and the authentication URLs. ## 4. Create Token You can use our wizard to handle the authentication process. This will take you to the external site, generate the token and pass this back to store in our product.\ After the callback process has completed you have the option to run a follow on monitor or workflow to handle the data returned. ## 5. Add the Authentication to the monitor Adding the Setting and the Token to the call is the last step, and we will take care of the rest. --- # Setting up an OAuth 2.0 Authentication > Set up an OAuth 2.0 authentication: create the auth setting, add a token from the provider, and use the auth setting in a monitor. Source: https://docs.apicontext.com/guides/authentication-settings/example-oauth-authentication-set-up ## Create an Authentication In the sidebar, under **Configure Monitoring**, select **Monitor Authentication** ([open it](https://client.apimetrics.io/auth/)), then select **Add new Auth Setting**. In the **Create Authentication** panel, set **Authentication Type** to **OAuth 2** and complete its fields. For OAuth 2.0, you need the Client ID and Client Secret. You usually get these from the API provider by registering an app with the provider's developer program. You also need an Authorize URL and a Get Token URL, which are in the provider's API documentation. ![Create Authentication panel set to OAuth 2, with the Authorize URL, Get Token URL, Advanced options, and Client ID and Client Secret fields](https://docs.apicontext.com/img/75e6133-Authentication.webp) Select **Save**. The auth setting's page then shows its **Callback URL**, `https://client.apimetrics.io/tokens/callback/`. Register this callback URL with the API provider to use the token wizard. ![Saved OAuth 2 auth setting showing its Authorize URL, Get Token URL, the Callback URL to register with the provider, and its Client ID](https://docs.apicontext.com/img/oauth2-auth-setting-callback-url.webp) ## Create a Token To create the token, open the auth setting and select **Add New Token**. In the **Add New Token** panel, enter a name for the token. Under **Get token from provider**, choose **Authorization Code** or **Client Credentials** from the **Grant Type** list, as the API documentation directs. For user-authenticated calls, Authorization Code is the usual choice. Enter any scopes the API documentation requires in **Scope**. ![Add New Token panel for an OAuth 2 auth setting with the Grant Type list open showing Authorization Code and Client Credentials, the Callback URL, and the Authenticate with Example OAuth 2 button](https://docs.apicontext.com/img/5c1bd52-Token.webp) When you select **Authenticate with ...** (where ... is the name of the auth setting), you are sent to the provider's site to authorize the token. Sign in with an account that is associated with the Client ID and Client Secret you used. If you are familiar with OAuth, you can also select **Enter token values manually** and create the token from the appropriate values. This is generally not recommended, although might be necessary in certain circumstances as often found that the automated token generation process fails for some reason. In this situation, it would normally be necessary to use a monitor to an authentication endpoint to obtain the values for the token, which would be extracted from the returned JSON payload. ![Auth setting detail page with its tokens table listing a saved token, with Expires, Expires In, and Last Updated columns](https://docs.apicontext.com/img/8845f1b-Auth_Tokens.webp) After the token generation has been authenticated by the API provider, you will be returned to APImetrics and will see the new token in your list of tokens for that API provider. ## Use the Auth Settings in a call When you setup or edit a call nex that uses the authentication, you can then choose the authentication and then the associated token from the dropdowns in the call editor. ![Monitor editor with the Authentication section highlighted, showing the Settings and Token dropdowns with an auth setting and token selected](https://docs.apicontext.com/img/9c62a1c-Using_Auth_Setting.webp) --- # Authentication in a Workflow > Creating a sequence of calls to obtain a token, save that token as a variable and then use the token in later monitors in the workflow. Source: https://docs.apicontext.com/guides/authentication-settings/authentication-in-a-workflow Depending on the configuration of the API security, you may need to obtain a token specific to a sequence of monitors.\ This approach should be used with non-standard OAuth configurations.\ The easy way to do this is with a workflow. The sequence will be as follows: Step 1 - make a POST to obtain a token\ Step 2 - Parse the returned content to save the token as a variable\ Step 3 and beyond - use the saved variable in following monitors as the token > **If possible use the Authentication Settings Manager** > > If possible we highly recommend using the authentication manager which will make it easier to keep the logic of obtaining and managing tokens up to date, separate from the monitors themselves. --- # Authentication Settings > Types of authentication APIContext supports natively, and the authentication manager that lets one setup authorize multiple monitors. Source: https://docs.apicontext.com/guides/authentication-settings APImetrics has an authentication manager that is used to simplify the process of handling authentication for monitors. If you have monitors with authentication, you can create a authentication setup that can be used to authorize multiple calls. [Authentication & OAuth - using the wizard](https://www.youtube.com/watch?v=SnAvuUCjXfA) ## Key Concepts APImetrics breaks authentication into two parts * The authentication setup type such as API Key or OAuth * The token used by the authentication service. ## Type of Authentication Supported * **Basic Authentication** - using a username and password in the call * **API Key** - a key placed in the header or the parameters of the call * **OAuth** - a multi-step authentication process involving a call to an external service to generate a token. ## OAuth Authentication OAuth is widely used standard for API authentication and authorization. APImetrics supports the following OAuth authentication flows in the product. * OAuth 1 * OAuth 2 * OAuth 2 + JWS * OAuth 2 + JWT > **You cannot share your tokens** > > An authentication can have many tokens associated with it. However, because of security issues, we limit the sharing of individual tokens. --- # Certificates > The Certificates page is a centralised location for your MTLS certificates, so you can use them across multiple different projects. Source: https://docs.apicontext.com/guides/authentication-settings/certificates Instead of individually adding certificates to every project you own and updating them individually whenever they expire, APImetrics has the Certificates page so that all certificates are global. Simply go to your Organization Settings and there is a Certificates tab. ![Organization Settings](https://docs.apicontext.com/img/b9086eb80d19239c6066b4b11c7921324a457dc602dd98212f554f95f801eb66-OrgSettings-Certificates.webp) ![Certificates Tab](https://docs.apicontext.com/img/144c3339dd2adbae106f974c7ca58e25a711fee9a8eb3bbd081d26bbc3a74437-Certificates-Tab.webp) ## Add a Certificate Simply, select the **Add Certificate button**. ![Certificates - Add Certificate](https://docs.apicontext.com/img/3c463a4bfa11d14a111056feae830842bedb3979eb745b1a595fe4f24d246f8b-Add_Certificate.webp) Enter a **Name** for your certificate, select "MTLS" as the 'Intended Use', then paste the **Certificate** & **Private Key** values into their respective fields. If applicable, provide a **Password**, and optionally select the projects to which you want to restrict this certificate. The private key can be unencrypted, or a traditional encrypted PEM key (one with a `Proc-Type: 4,ENCRYPTED` header). An encrypted key needs its **Password**; without it the form shows "Password is required for encrypted private keys". If a pasted certificate or key is cut short, the form reports that it "appears to be truncated": paste the whole value again, including the `BEGIN` and `END` lines. ![MTLS Certificate Fields](https://docs.apicontext.com/img/4c1bcac6d625729348829dad3b30c5e17c22c4307d0c6276ef46034af7c758e9-MTLS_Certificates.webp) Click the **Add** button to finish uploading the Certificate. ![Certificates form with the Add button highlighted to upload the certificate](https://docs.apicontext.com/img/6e64315-image.webp) ## Update a Certificate APIContext will make you aware if a Certificate is about to or has already expired by highlighting the **Expires** text in orange (60 days or fewer until expiration) or red (already expired). To update one of your Certificates, simply select the row from the table and it will expand and show the same form as **Add Certificate**. ![Expanded certificate row showing the editable Certificate and Private Key form](https://docs.apicontext.com/img/43dc846-image.webp) Add your new **Certificate** and **Private Key**. Once completed, select **Save** and the process will be completed. ![Expanded certificate edit row with the Save button highlighted](https://docs.apicontext.com/img/2376a25-image.webp) ### Caching of Certificates The certificates are cached so after a new certificate is uploaded it might be a certain period (up to an hour or more) before the cache is flushed and the new certificate comes into use. --- # Workflows Edit > How to edit a workflow's monitors and order, run it manually with runtime variables, and create schedules for worldwide or specific locations. Source: https://docs.apicontext.com/guides/creating-a-workflow/workflows-edit ## Editing a Workflow You can edit a workflow by selecting the row you want from the list of **Workflows**. From here, you can change the name of the **Workflow** or **Run Workflow Now**. This shows monitors that make up the workflow and the variables, if any, that are set at each stage of the workflow. More monitors can be added by selecting the **+** button on any of the monitors to add one after that call or the **Add Step** button as well as the **Add New Monitor** button. The monitors can also be reordered using the arrows on the left of the row and deleted using the bin icon on the right of the row. ![Edit Workflow page showing the steps, add and reorder controls, Run Workflow Now, and scheduling](https://docs.apicontext.com/img/bdb6adb-Screenshot_2024-02-19_at_17.53.35.webp) To edit the monitors, select the **Edit** button to open the individual monitor or toggle the **monitor edit mode** for a quick edit mode. ![Edit Workflow page with the API call edit mode toggle highlighted for quick monitor editing](https://docs.apicontext.com/img/f82c1f1-image.webp) ![Workflow in monitor edit mode showing an editable step row with HTTP method, path, auth, and token fields](https://docs.apicontext.com/img/522ff02-Screenshot_2024-02-20_at_12.19.15.webp) ### Running a Manual Workflow If you select the dropdown on the **Run Workflow Now** button, you can choose from the different agents we have available or Google US Central 1 if none are chosen. ![Run Workflow Now dropdown open listing agent locations to run the workflow from](https://docs.apicontext.com/img/1bdc50a-Screenshot_2024-02-19_at_18.15.07.webp) #### Setting Runtime Variables Runtime variables can also be set here however, these are temporary and only used at runtime and not during scheduled monitoring. Select **Set runtime variables** to start. ![Workflow configuration with the Set runtime variables link highlighted under Run Workflow Now](https://docs.apicontext.com/img/778a842-image.webp) Next, select the **Add** button to create a new variable entry. ![Runtime variables panel with the Add button highlighted to create a new variable entry](https://docs.apicontext.com/img/41829d5-image.webp) Next, fill in the variable and value fields, and select the **+** to add the variable to the runtime variables. ![Runtime variables panel with variable and value fields and the plus button to add the variable](https://docs.apicontext.com/img/6f9ae5a-image.webp) ## Scheduling a Workflow Scheduling **Workflows** is the same process as scheduling an individual monitor. At the bottom of the **Workflows Edit** tab, you can create schedules for your **Workflow** and turn on and off different schedules you have created. ![Scheduling section at the bottom of the Edit Workflow page with the New Schedule button highlighted](https://docs.apicontext.com/img/61cb34e-Screenshot_2024-02-20_at_13.43.31.webp) To create a schedule, select the **New Schedule** button. ![Workflow Monitoring section with the New Schedule button highlighted above the schedule cards](https://docs.apicontext.com/img/b0da3ef-image.webp) A popup will open where you can **name** your schedule, choose the **frequency** it runs. ![Edit Schedule dialog with fields for the schedule name and run frequency](https://docs.apicontext.com/img/a4f69b2-Schedule_Form.webp) You can also choose whether you want it to run **worldwide** or choose from different **continents** or **cloud service providers**. ![Edit Schedule dialog Node Selection dropdown for choosing worldwide, continents, or cloud providers](https://docs.apicontext.com/img/8c090f9-Node_Selection.webp) If you select the **Advanced** option, you can fine-tune even further by selecting specific **locations**. ![Edit Schedule Node Locations tab listing individual AWS regions to select specific locations](https://docs.apicontext.com/img/091956d-Node_Locations.webp) Finally, you can choose what **retry on failure method** you would like if any and if you are using the **Postman Monitoring** feature, you can choose this scheduling here. Once you're happy with your schedule, select the **Save changes** button and your schedule will be created. ![Edit Schedule dialog with name, frequency, worldwide regions, retry methods, and Save changes button](https://docs.apicontext.com/img/2deef24-image.webp) ## Preventing parallel runs A high-frequency schedule or a long workflow can start a new run while the last one is still going. To stop that, open the workflow, select the **Advanced** tab, and turn on **Ensure the workflow does not run in parallel**. With the switch on: * **One run at a time, everywhere.** The lock belongs to the workflow, not to a location, so a run at one location blocks runs at every other location. * **Every way of starting a run is covered.** Scheduled runs, **Run Workflow Now**, and runs started through the API all check the lock before their first step. * **A blocked run is skipped, not queued.** Its workflow result is marked complete with no steps run. The next scheduled run tries again. * **The lock ends with the run.** It is released when the run finishes. * **An idle run loses the lock after 5 minutes.** If a run has not finished a step for more than 5 minutes (a slow step, or a delay or retry between steps), the next run takes the lock and the two runs overlap. A long workflow keeps the lock as long as it keeps finishing steps. > **Caution** > > The switch reliably stops runs that start a few seconds apart. Two runs that start at the same moment, for example a > schedule that starts the workflow at several locations at once, can both run. To avoid that, schedule the workflow > from one location, or space the schedules apart. --- # Workflows Results > The Workflow Results tab allows you to easily see how your Workflows are performing across our agents. Source: https://docs.apicontext.com/guides/creating-a-workflow/workflows-results Selecting the **Results** tab brings up a summary of the executions of the **Workflow**. You can drill down further by clicking on the row you are interested in. ![Workflow Results tab summarizing executions by start time, cloud, region, country, and final result](https://docs.apicontext.com/img/16ca61c-Screenshot_2024-02-16_at_13.53.22.webp) From here you can view more in-depth details on the **Results** for the **Workflow**. ![Detailed workflow result showing run location, timing breakdown bar, and per-monitor results](https://docs.apicontext.com/img/a81758c-Screenshot_2024-02-16_at_14.28.54.webp) You can also drill down deeper and view the individual monitors from here as well by selecting the row of the monitor you are interested in. ![Individual monitor result for a workflow step showing call details and a timing breakdown bar](https://docs.apicontext.com/img/1567233-Screenshot_2024-02-16_at_14.31.21.webp) --- Workflow results include full step-level trace detail that can be [exported via OpenTelemetry](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-with-opentelemetry.md). Learn more about [workflows and traces](https://apicontext.com/features/workflows-and-traces) on the platform site. --- # Using Variables in Workflows > How to capture values with assertions, store them in an environment variable, and pass them between monitors in a workflow, such as OAuth tokens. Source: https://docs.apicontext.com/guides/creating-a-workflow/setting-environment-variables-in-a-workflow If you need to store a variable for use within a workflow, the most straightforward way to achieve this is to use [Assertions](https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics.md) as part of a [Workflow](https://docs.apicontext.com/guides/creating-a-workflow.md). The process is simple: 1. Use Assertions to capture the value. 2. Set an environment variable to the captured value. 3. Use the environment variable in your monitors. This could be used to set OAuth tokens for use in other calls where a workflow runs every few hours to set the token or refresh the token used in several calls. ## Use Assertions to Capture the Values In the Assertions section of the Monitor Edit tab, you can extract variables from your JSON or XML content and save them to a variable. For more in-depth tutorials on these content types, follow the [JSON parsing tutorial](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-json-content.md) and the [XML parsing tutorial](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-xml-content.md). Firstly, go to the monitor where you want to extract your variables. Scroll to the **Assertions** section in the **Edit** tab. From here you can put the JSON path of the variable you want and assign a name for the variable. **Save** these changes. ![Monitor Edit Assertions section extracting a JSON value into the ACCESS_TOKEN variable](https://docs.apicontext.com/img/569c681-Screenshot_2024-02-20_at_14.08.42.webp) ## Set an Environment Variable to the Captured Value Next, create a new monitor or use an existing one to set the variable. This example sets the variable 'access\_token' to the value set in the previous monitor. ![Monitor Edit page for a Create Pet call configuring the access_token environment variable](https://docs.apicontext.com/img/4906066-Screenshot_2024-02-20_at_14.16.56.webp) ## Use the Environment Variable in your monitors Now, you will be able to see the different variables passing between your monitors in your Workflow. ![Edit Workflow steps showing runtime variables used and set passing between monitors](https://docs.apicontext.com/img/9a9a3e3-Screenshot_2024-02-20_at_14.18.12.webp) --- # Adding a Delay to a Workflow > How to add a pause between workflow steps using the delay API, which supports up to 10 seconds per call and can be chained for longer delays. Source: https://docs.apicontext.com/guides/creating-a-workflow/adding-a-delay-to-a-workflow If your process requires a specific delay in a sequence, for example, your database requires a particular period of time between queries or you wish to simulate a user making a decision for a date always in the future of when the call was made. Then you can use the following API as a part of the workflow: ```http http://google.api.expert/delay/(delay in seconds) ``` The syntax for a 2-second delay is: ```text http://google.api.expert/delay/2 ``` > The delay API supports a maximum delay of **10 seconds** per call. If you need a longer delay, you can chain multiple delay APIs in your workflow. For example, to achieve a 15-second delay, combine a 10-second delay API with a 5-second delay API: ``` http://google.api.expert/delay/10 http://google.api.expert/delay/5 ``` --- # Workflows > Want to execute a set of API calls to simulate a customer interaction or to pass variables between calls? Workflows makes this an easy process Source: https://docs.apicontext.com/guides/creating-a-workflow **[Workflows](https://apicontext.com/features/workflows-and-traces)** allow you to create a series of monitors (spanning API, browser, and MCP surfaces) that run in sequence. You can extract variables from the output of earlier calls and use them as input to later ones. This simulates real-world business processes that involve multiple linked monitors, giving more realistic monitoring with full step-level trace detail. The monitors can also be completely independent of each other. Just like a normal monitor in APImetrics, **Workflows** are deployed to be run periodically from agents in the same way. ## Example Workflow Below is an example of a **Workflow** to give a clearer idea of the possibilities of a **Workflow**. 1. monitor that creates a user in a particular system. Extract the user ID from the returned payload. 2. monitor that creates a record associated with the user account for the user ID. Extract the record ID from the returned payload. 3. monitor that obtains the record associated with the user account for the user ID and the record ID. Validate the returned payload using API Conditions to demonstrate that the record was created successfully. 4. monitor that deletes the record associated with the user account for the user ID and the record ID. 5. monitor that obtains the record associated with the user account for the user ID and the record ID. Validate the returned payload using API Conditions to demonstrate that the record was deleted successfully (trying to obtain a deleted record should lead to the returned payload containing an error message). 6. monitor that deletes the user account associated with the user ID. > **Variables in workflows** > > A variable used in a Workflow only persists for use in that Workflow. We provide pre-set variables for services like DATE and TIME, and global variables that can be used to handle externally generated tokens and IDs. To learn more about these, see [APImetrics-defined variables](https://docs.apicontext.com/concepts/environment-variables/apimetrics-defined-variables.md). ## Creating a Workflow **Workflows** can be found under **Configuration** in the sidebar. ![Sidebar Configure Monitoring menu with the Workflows option highlighted](https://docs.apicontext.com/img/fab1fa0-image.webp) To create a new **Workflow**, enter a name in the text field and then select the **Add** button. ![Workflows page with the New Workflow name field and Add button highlighted](https://docs.apicontext.com/img/48d5628-image.webp) If you already have created some **Workflows**, they will be listed on the page. ![Workflows page listing existing workflows with stop on failure, monitored, and last updated columns](https://docs.apicontext.com/img/83da171-Screenshot_2024-02-15_at_15.14.14.webp) To **Edit** a **Workflow**, select the row containing the **Workflow** and it will direct you to the **Edit** page. ![Workflows list with a workflow row selected, opening the Edit Workflow page](https://docs.apicontext.com/img/512d14e-Screenshot_2024-02-15_at_15.17.24.webp) To add an existing monitor to your **Workflow**, select the **Add Step** button below the **Steps** table. ![Edit Workflow page with the Add Step and Add New Monitor buttons highlighted below the Steps table](https://docs.apicontext.com/img/faa8354-image.webp) After this, you can select from an existing monitor from the dropdown. ![Edit Workflow step with the Select a monitor dropdown open listing existing monitors to add](https://docs.apicontext.com/img/61e257e-image.webp) You can also create a new monitor within the **Edit Workflow** page by selecting the **Add New Monitor** button. ![Edit Workflow page with the Add New Monitor button highlighted to create a monitor within the workflow](https://docs.apicontext.com/img/ff29b60-image.webp) Enter the details in the prompt, choosing the **Method**, **URL**, and **Name** before selecting the **Add** button to complete the new monitor. ![New monitor entry form with Method, URL, and Name fields and an Add button inside the workflow](https://docs.apicontext.com/img/07d986b-image.webp) ## Variables and Conditions Passing variables between **Workflows** is a key part of simulating a real business interaction. We have tutorials on parsing content in [JSON](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-json-content.md) and [XML](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-xml-content.md). There is also a set of pre-set variables that we provide, see [our pre-set variables](https://docs.apicontext.com/concepts/environment-variables/apimetrics-defined-variables.md). In case of a failure, there are Conditions, which allow you to stop **Workflows**. See the [section on Assertions](https://docs.apicontext.com/guides/set-conditions.md) and conditions for more details on handling these situations. ## Copy or move a workflow To reuse a workflow in another project, or to move it there with its monitors, use the **Copy** and **Move** buttons at the top of its page. See [Copy or move a workflow](https://docs.apicontext.com/guides/projects/copy-or-move-a-workflow.md). --- # Importing from Postman > Import your Postman Collections into APImetrics using a Postman API key. Source: https://docs.apicontext.com/guides/importing-api-calls/importing-from-postman > **Monitor Postman Collections** > > Importing Postman Collections copies the monitors into your APImetrics account - if you're rather keep all the configuration with Postman, you can use our Postman Collection runner instead. More information on how to [Monitor Postman Collections available here.](https://docs.apicontext.com/guides/working-with-postman/monitor-postman-collections.md) To import from Postman directly, first you need to generate a Postman API key. We will use this to fetch your Postman Collections. More information on how to access or generate a key is available here: [https://learning.getpostman.com/docs/postman/postman_api/intro_api/#authentication](https://learning.getpostman.com/docs/postman/postman_api/intro_api/#authentication).\ The first step is to log into postman and [view your dashboard](https://app.getpostman.com/dashboard/integrations) and select Integrations: ![Postman workspace top navigation with the Integrations tab circled](https://docs.apicontext.com/img/af02104-Screen_Shot_2019-03-27_at_4.30.09_PM.webp) Browse integrations and select Postman API ![Postman Browse Integrations view with the Postman API integration card highlighted](https://docs.apicontext.com/img/5949a43-Screen_Shot_2019-03-27_at_4.30.43_PM.webp) Select Get API Key to generate an API key: ![Postman API integration details page with the Get API Key button highlighted](https://docs.apicontext.com/img/aff1071-Screen_Shot_2019-03-27_at_4.30.55_PM.webp) Once generated, copy your Postman API key, enter it in the importer, and select **Validate!**: ![Importer step to enter your Postman API key and select Validate!, with the steps Postman API key, Pick Collection, Validate Collection, Preview Import, and Complete Import](https://docs.apicontext.com/img/c9dfc5c-Screen_Shot_2019-03-27_at_12.54.14_PM.webp) Enter your Postman API Key As long as the API key is correct, and you have Postman quota available, we will show you the list of Collections available to import: ![Pick Collection step listing the available Postman collection APImetrics APIs](https://docs.apicontext.com/img/43f1355-Screen_Shot_2019-03-27_at_12.54.32_PM.webp) The list of Postman collections - here, just one - "APImetrics APIs" Click on the Collection you want to import. We will then validate that we can handle the file format, and warn you of any potential warnings or errors: ![Validate Collection step confirming the specification is valid with a missing-description warning](https://docs.apicontext.com/img/05b00b5-Screen_Shot_2019-03-27_at_12.54.43_PM.webp) Validation complete Assuming everything is okay, click Next. We will then show you the Workflows and APIs we will generate at the final step: ![Preview Import step listing the Workflows and API calls the importer will generate or update](https://docs.apicontext.com/img/b4074c7-Screen_Shot_2019-03-27_at_12.55.03_PM.webp) Workflows and monitors to be generated In the dropdown menus, you can select existing Workflows and monitors to overwrite. If you have previously imported this collection, we try to match the calls with the previously imported calls.\ If you're happy, click next to generate the Workflows and monitors: ![Complete Import step listing the Workflows and API calls the importer saved](https://docs.apicontext.com/img/611a96e-Screen_Shot_2019-03-27_at_12.55.54_PM.webp) The Workflows and monitors generated The import has completed. Note you may need to [set up any environment variables](https://docs.apicontext.com/guides/creating-a-workflow/setting-environment-variables-in-a-workflow.md) your monitors require. You may also want to check that your [monitors have the correct Authentication settings](https://docs.apicontext.com/guides/monitor-authentication.md). Once you've reviewed your calls, you should [set up a schedule](https://docs.apicontext.com/guides/schedule-monitors.md) for your new workflows. --- # Importing an API specification > Import API calls from an OpenAPI or Swagger specification URL into APImetrics workflows and monitors. Source: https://docs.apicontext.com/guides/importing-api-calls/importing-an-api-specification You may import an API specification from a publicly accessible URL. Once imported, APIContext can continuously compare production responses against the spec. See [Build to Specifications](https://apicontext.com/features/build-to-specifications) for how automated OAS comparison works on every deploy. To get started, enter your specification's URL: ![Importer field to enter your API specification public URL, prefilled with the Swagger Petstore JSON, and a Validate button](https://docs.apicontext.com/img/f342008-Screen_Shot_2019-03-27_at_5.02.27_PM.webp) Click Validate to check we can support your specification: ![Validation result confirming the specification is valid, with a missing description warning and a Next button](https://docs.apicontext.com/img/a92a5ac-Screen_Shot_2019-03-27_at_5.03.05_PM.webp) We will warn you of any potential warnings or errors with the specification. If happy, press Next to continue to the preview: ![Importer preview listing Swagger Petstore workflows and pet API calls, each with a dropdown to create new or overwrite](https://docs.apicontext.com/img/0a4add1-Screen_Shot_2019-03-27_at_5.03.16_PM.webp) In the dropdown menus, you can select existing Workflows and monitors to overwrite. If you have previously imported this collection, we try to match the calls with the previously imported calls.\ Finally, click next to generate the Workflows and monitors: ![Importer completion summary listing the saved Swagger Petstore workflows and their generated API calls](https://docs.apicontext.com/img/816afdb-Screen_Shot_2019-03-27_at_5.03.40_PM.webp) The import has completed. Note you may need to [set up any environment variables](https://docs.apicontext.com/guides/creating-a-workflow/setting-environment-variables-in-a-workflow.md) your monitors require. You may also want to check that your [monitors have the correct Authentication settings](https://docs.apicontext.com/guides/monitor-authentication.md). Once you've reviewed your calls, you should [set up a schedule](https://docs.apicontext.com/guides/schedule-monitors.md) for your new workflows. --- # Importing from APIMATIC > Import API calls from APIMatic into APImetrics using your APIMatic API integration key. Source: https://docs.apicontext.com/guides/importing-api-calls/importing-from-apimatic To import from APIMATIC, we need your API's API integration key.\ First visit your [APIMATIC dashboard](https://www.apimatic.io/dashboard) and view your APIs: ![APIMATIC dashboard showing API cards such as APImetrics APIs and APIMATIC Calculator with Generate and Edit buttons](https://docs.apicontext.com/img/958d988-Screen_Shot_2019-03-27_at_4.49.18_PM.webp) Use the menu to select "API Integration Keys": ![APIMATIC API card menu open with API Integration Keys highlighted among Import, Fork, Export and View Logs options](https://docs.apicontext.com/img/dca71e3-Screen_Shot_2019-03-27_at_4.49.26_PM.webp) Use the copy button to copy the "API key": ![APIMATIC API Integration Keys dialog with the API KEY field highlighted for copying](https://docs.apicontext.com/img/5d47a7e-Screen_Shot_2019-03-27_at_4.49.47_PM.webp) Paste your API key into APImetrics importer at the prompt: ![APImetrics importer prompt to enter your APIMATIC API key with a Validate button](https://docs.apicontext.com/img/8bed879-Screen_Shot_2019-03-27_at_4.53.57_PM.webp) Select Validate, and we ensure we import the definition. We will show you any errors or warnings which you may wish to correct. ![Importer validation result confirming the specification is valid, with a missing description warning and a Next button](https://docs.apicontext.com/img/8a3507b-Screen_Shot_2019-03-27_at_4.54.24_PM.webp) Click Next to see which Workflows and Monitors we will generate: ![Importer preview listing workflows and API calls to generate, each with a dropdown to create new or overwrite existing](https://docs.apicontext.com/img/9f9be5d-Screen_Shot_2019-03-27_at_4.54.37_PM.webp) Use the dropdown selectors to choose whether to create a new Workflow / Monitor or overwrite an existing one.\ When you're happy, click Next to start the import: ![Importer completion summary listing the workflows and API calls that were saved during the import](https://docs.apicontext.com/img/a5883d5-Screen_Shot_2019-03-27_at_12.55.54_PM_copy.webp) The import has completed. Note you may need to [set up any environment variables](https://docs.apicontext.com/guides/creating-a-workflow/setting-environment-variables-in-a-workflow.md) your monitors require. You may also want to check that your [monitors have the correct Authentication settings](https://docs.apicontext.com/guides/monitor-authentication.md). Once you've reviewed your calls, you should [set up a schedule](https://docs.apicontext.com/guides/schedule-monitors.md) for your new workflows. --- # Importing API Calls > How to bulk import API definitions into APImetrics from Postman, APIMATIC, or a specification URL, with a list of supported specification formats. Source: https://docs.apicontext.com/guides/importing-api-calls ## Key Concepts It is possible to bulk import API definitions in a number of standardized formats into APImetrics. This makes it easier to setup monitors when a large number of tests for different endpoints are required. You may import your API definitions either directly from [Postman](https://docs.apicontext.com/guides/importing-api-calls/importing-from-postman.md), from [APIMATIC](https://docs.apicontext.com/guides/importing-api-calls/importing-from-apimatic.md), or by giving us the [URL of a specification](https://docs.apicontext.com/guides/importing-api-calls/importing-an-api-specification.md). With the help of our friends at APIMATIC, we can import a wide variety of formats. ## Supported Specification Formats With the help of our friends at [APIMATIC](http://apimatic.io), we support the following API specification formats: * API Blueprint * OpenAPI/Swagger 1.0 - 1.2 * OpenAPI/Swagger 2.0 JSON * OpenAPI/Swagger 2.0 YAML * WADL - W3C 2009 * WSDL 1.1 - W3C * Google Discovery * RAML 0.8 - 1.0 * I/O Docs - Mashery * HAR 1.2 * Postman Collection 1.0 - 2.0, 2.1 * APIMATIC Format * Mashape * OpenAPI Spec 3.0 (JSON) * OpenAPI Spec 3.0 (YAML) * Insomnia Export Format 3.0 ## Using the Importer For in-depth help, see the help pages for [Postman](https://docs.apicontext.com/guides/importing-api-calls/importing-from-postman.md), [APIMATIC](https://docs.apicontext.com/guides/importing-api-calls/importing-from-apimatic.md), or [by URL of a specification](https://docs.apicontext.com/guides/importing-api-calls/importing-an-api-specification.md). Note: Once the import has completed, you may need to [set up any environment variables](https://docs.apicontext.com/guides/creating-a-workflow/setting-environment-variables-in-a-workflow.md) your monitors require. You may also want to check that your [monitors have the correct Authentication settings](https://docs.apicontext.com/guides/monitor-authentication.md). Once you've reviewed your calls, you should [set up a schedule](https://docs.apicontext.com/guides/schedule-monitors.md) for your new workflows. --- # Project Dashboard > The Project Overview dashboard shows every scheduled monitor in a project with its key metrics, such as hourly and recent results, for the current period. Source: https://docs.apicontext.com/guides/analytics/project-home The Project Overview is your at-a-glance health dashboard for a project. It shows all monitors ([API](https://apicontext.com/features/api-monitoring), [browser](https://apicontext.com/features/website-monitoring), and [MCP](https://apicontext.com/features/ai-monitoring)) that have been added to a schedule alongside their key metrics for the current reporting period: - **Hourly results**: a color-coded bar chart of the last 24 hours (green = passing, red/yellow = failures or warnings). Click any bar to jump to results for that hour. - **Recent results**: pass/fail indicators for the most recent individual runs. - **Quality score**: the CASC quality score (0–10) for the monitor's latest Insights Report. - **Availability %**, **Slow %**, and **Avg. Total latency**: aggregate SLA-style metrics for the period. Clicking the monitor name opens its Edit view. The quick-action icons on the right let you jump directly to the Insights Report (API monitors only) or Stats page for that monitor. Monitors that have been created but not yet added to a schedule appear in the **Monitors not in Schedules** table below. Two settings on a monitor's **Advanced** tab, under **Home page behavior**, override which table a monitor appears in: **Always in monitored list** and **Always in not monitored list**. See [Remove a monitor from the monitored list](https://docs.apicontext.com/guides/quality-analytics/omit-from-casc-score.md). To stop conformance checks on a monitor, use **Skip Conformance Checks** instead. See [Exclude APIs from Conformance checks](https://docs.apicontext.com/guides/conformance/exclude-conformance-monitoring.md). ![Project Overview showing the Monitors in Schedules table](https://docs.apicontext.com/img/8062d83-home_page_navigation.webp "Project Overview — Monitors in Schedules") --- # Data Types > Key terms for APIContext reporting: the four primary types of data aggregation, which are Quality Analytics, Reports, Results, and Stats. Source: https://docs.apicontext.com/guides/analytics/data-types APImetrics has 4 primary types of data aggregations (see [Reporting & Analytics](https://apicontext.com/features/api-reporting-analysis) for the full capabilities including KPI dashboards, latency waterfalls, and automated compliance reports): * Quality Analytics: machine-generated analysis of API performance over a week or month * Reports: configurable reports on individual or groups of APIs * Results: the detailed results of a specific monitor * Stats: detailed analysis of the performance of a specific API You can't access Stats directly from the Reporting menu but links to stats are available from any monitor. > **You need to schedule calls to see data** > > We can only report on calls that have been scheduled and are generating data! ## Types of Data Available APImetrics provides several levels of reporting for API performance. This includes the following: * General pass/fail reports * API level stats including detailed geographical analysis * Latency analysis All data is stored by call breakdown and percentile of the data. Call breakdowns stored are: * DNS look up time * TCP connect time * HTTPS handshake time * Upload time * Processing time * Download Time * Total Time * Time to first byte Data can be displayed in the following ways: * Pass fail graphs * Latency graphs * Latency histograms * Heatmaps showing either a time period or a cumulative time period * Return packet size graphs * Maps showing latency by geography > **Tip** > > SLO and SLA data can be exported as compliance-ready evidence. See [SLO/SLA Management](https://apicontext.com/features/api-sla-and-slo-management) for details on regulator-ready reporting and vendor attribution. --- **See also:** - For individual call details, see [View results](https://docs.apicontext.com/guides/view-results.md). - To understand quality scores, see [CASC Score concept](https://docs.apicontext.com/concepts/casc-score.md). --- # Quality Analytics Reports > Understand the Insights Report for a monitor, a single view with sections for summary information, outlier analysis, and outlier incidence. Source: https://docs.apicontext.com/guides/analytics/quality-analytics-reports Quality Analytics is part of APIContext's [reporting and analytics](https://apicontext.com/features/api-reporting-analysis) suite. The Insights Report for an API monitor is a single consolidated view. Reading top to bottom, it is broken down into the following sections: * CASC score - the score for the monitor plus a **Factors affecting CASC score** panel describing the issues impacting that score * Pass rates - the Pass Rate and Effective Pass Rate, with the number of API calls analyzed and the estimated downtime * Outliers and Failures - **Most failures** and **Most outliers** broken down by Cloud, Region, Country, and Node * Latency - Mean Latency, Standard deviation, Slowest locations, and Most variation broken down by Cloud, Region, or specific cloud location ![Full Insights Report for GET /get showing CASC score 9.36, Pass Rate 100%, Effective Pass Rate 98.2%, outlier breakdowns, mean latency, and standard deviation panels](https://docs.apicontext.com/img/28540d2-Insight_Report_View.webp "Insights Report — full view") ## Summary Information The top of the report shows the CASC score for the monitor next to a **Factors affecting CASC score** panel. This panel explains the score in context: whether the monitor is performing perfectly or near to it, how it compares to the previous period, and any minor or major issues such as a few outliers or elevated latency. Immediately below, the Pass Rate and Effective Pass Rate summarize how many API calls passed, with the failure and outlier breakdowns following beneath. ![Top of the Insights Report showing the CASC score of 9.36 beside the Factors affecting CASC score panel explaining minor issues](https://docs.apicontext.com/img/46c8804-insights_CASC_summary.webp) ## Outlier Analysis The outlier analysis graphically shows latency outliers by type: * cloud location they occurred * failures\ The light background is an indication of the number of outlying events that day. The lighter shading in the background indicates that a cluster has been detected where the outlying events seem to be related.\ The drop down at the bottom of the view allows you to jump straight to a specific outlying result. ![Outlier Analysis panel plotting latency outliers over time with shaded backgrounds marking clustered outlying events](https://docs.apicontext.com/img/ac381d1-Outlier_Analysis.webp) ## Outlier Incidence The final set of views can provide you with a comparative view by Cloud, Region, or individual cloud location. ![Outliers and Failures donut charts comparing outlier and failure incidence by cloud, region, or individual cloud location](https://docs.apicontext.com/img/e1e1383-Outlier_and_Failure_by_Incident.webp) --- # Creating Reports > Creating a report provides a simple summary of data that can be shared internally or externally. Source: https://docs.apicontext.com/guides/analytics/creating-reports ## Key Concepts Reports are a great way of summarizing the statistics associated with calls and seeing at a glance how an API has been behaving. ## Creating a Report from an Monitor or Workflow You can create reports in several ways: 1. From the Homepage, CREATE REPORT is above the domain filters 2. From an API or Workflow EDIT view 3. From the API list 4. From the Report menu\ Once created, reports can be edited. ![Actively Monitored API Calls header with the Create Report action highlighted above the domain filters](https://docs.apicontext.com/img/897348b-create_report_12.webp) ## Creating From the Report Menu In the report view list on the left hand navigation, select Create New Report. Reports are split into GROUPS. In each group you can chose APIs to include. ![Edit Report screen with numbered controls for report name, group name, the API Call picker, report actions, and public sharing](https://docs.apicontext.com/img/084d5b1-edit_report.webp) In the report editor: 1. Report Name - editable 2. Group Name - editable 3. API Picker > add an API to a report 4. Report controls: * VIEW - see the report * COPY - make a copy of your report in the project * MOVE - move the report to another project 5. Public Sharing - create a public dashboard of your report ### Reorder groups and monitors Drag and drop to change the order of your report: * Drag a **group** to move it up or down the report. * Drag a **monitor** within a group, or into a different group. The report view shows rows in the order you set in the editor. Changes are saved when you save the report. ## Reports at a glance ![Example report with numbered controls for granularity, metric, date, timezone, top 5% breakdown, pass rates, CASC score, and latency](https://docs.apicontext.com/img/895dae0-example_report_1.webp) 1. Select time period for report > day, month, year 2. Select report call time slice > DNS, TLS, TCP, Upload, Processing, Download 3. Date Picker 4. Set or override local Timezone 5. Breakdown of the last 5% of calls 6. Pass/Fail/Warning percentages 7. CASC Score - will take you to the insights view 8. Latency breakdown 9. Report controls * Edit * Status views for public sharing > grid or list options * CSV download (downloads the statistics currently shown) * Copy: copy the report into this project or another one ([Copy or move a report](https://docs.apicontext.com/guides/projects/copy-or-move-a-report.md)) * Move: move the report to another project * Print > print a PDF formatted version of the report Report tables no longer include a location column. To see results by location, use the location breakdown table on the report. ## Making a Report Public In the edit screen, select the 'Make report public' checkbox. When you view the report you'll have 2 options either the last week, showing uptime in the last hour, week, or day, or the last 15 minutes. You can also send a URL for the report to your colleagues that they can view if they have an APImetrics account and permission to view the report. --- # Public Status Reports > Reports can be shared publicly either as a webpage or embedded as a script in your own site Source: https://docs.apicontext.com/guides/analytics/public-status-reports > **Tip** > > Public status reports are one part of APIContext's [reporting and analytics suite](https://apicontext.com/features/api-reporting-analysis), which also includes KPI dashboards, latency trend analysis, and automated compliance reports for stakeholders. ## Making a report public All reports can be set to public when you edit them. This is down by selecting the toggle ![Report edit toolbar with the Enable Status view toggle set on to make the report publicly accessible](https://docs.apicontext.com/img/c1db22e-share_toggle.webp) ## Types of public report There are several types of public report option: 1. Status View (Weekly) - this has the last hour, day, and week in terms of uptime 2. Status View (15 minutes) - this shows just the last 15 minutes 3. Status View (Grid) - this shows a grid of blocks each representing a monitor ## Changing Grid View or Time Slice You can change the nature of the grid by editing the URL used to display the report. The options are: ?grid=\[number] | Grid = \[number] | Type of grid | | --- | --- | | 2 | 6 columns across | | 3 | 4 columns across | | 4 | 3 columns across | ## Time Period You can alter the time period displayed by changing the 'minutes' setting to the number of minutes you wish to show. ## Sharing Publicly Public reports are served from a lightweight standalone status page, so they load quickly when embedded in your own site. Existing links and embed scripts continue to work with no changes. You can share the reports in 2 ways: As a webpage: we provide a link that will open a blank webpage containing the report. ```text https://client.apimetrics.io/tools/1/reports/[reportGUID]/?grid=3&minutes=15 ``` As an embedded frame in your own page. The report can be shared from the script tag which will have the format: ```text ``` ## Creating Custom Reports All the data used in reports can be accessed via our APIs, which can be reviewed from the API documentation [Report Object](https://docs.apicontext.com/reference/api-full/get-report) --- # Investigation Mode > Investigation Mode is a way to drill into results quickly and see what happened around that result Source: https://docs.apicontext.com/guides/analytics/investigation-mode ## Starting an investigation - find the problem The fastest way is to filter your results based on the unexpected event, in the example here we know we had some unexpected HTTP 4XX results and we have filtered the results to see them. Clicking on one of them expands the result. ![Expanded call result with the Investigate section highlighted in the left sidebar](https://docs.apicontext.com/img/471fd40-investigation_mode_1.webp) On the left hand side, you'll see the "Investigate' section which includes a link for 'see the results around this one. Clicking on it launches investigation mode, which will share the results immediately before and after the issue. ![Investigation mode showing the call results immediately before and after the selected issue](https://docs.apicontext.com/img/ea55530-investigation_mode_2.webp) You can leave investigation mode at any time by clicking on the toggle in the top, middle to return to the normal results list. ## Access the Results from the Stats Tab One of the monitor edit tabs shows you detailed results for the API broken down by time period. Clicking on any of those will also take you to the results view. --- # Expanded Alerts > Want to send our data to another platform to view there? Use our Expanded Alerting Webhooks Source: https://docs.apicontext.com/guides/alerting/expanded-alerting APIContext's [alerting](https://apicontext.com/features/alerting) integrates with 30+ platforms via OpenTelemetry and native webhooks. Below are the tutorials for each platform: * [Alibaba Cloud](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-alibaba-cloud-via-opentelemetry.md) * [AWS](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-aws-via-opentelemetry.md) * [Axiom](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-axiom-via-opentelemetry.md) * [Cisco](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-cisco-appdynamics-via-opentelemetry.md) * [Datadog](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-datadog.md) * [Dynatrace](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-dynatrace.md) * [Docker](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-docker-via-opentelemetry.md) * [Elastic](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-elastic-via-opentelemetry.md) * [F5](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-f5.md) * [Fastly CDN](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-fastly-cdn-via-opentelemetry.md) * [Go SDK](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-go-via-opentelemetry.md) * [Google Cloud Platform](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-google-cloud-platform-via-opentelemetry.md) * [Honeycomb](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-honeycomb-via-opentelemetry.md) * [IBM Instana](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-ibm-instana-via-opentelemetry.md) * [Java SDK](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-java-via-opentelemetry.md) * [Logz.io](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-logzio-via-opentelemetry.md) * [Microsoft Azure Monitor](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-microsoft-azure-monitor-via-opentelemetry.md) * [Mulesoft](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-mulesoft-via-opentelemetry.md) * [New Relic](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-new-relic-via-opentelemetry.md) * [Nginx](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-nginx-via-opentelemetry.md) * [NodeJS](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-nodejs-via-opentelemetry.md) * [OpenTelemetry](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-with-opentelemetry.md) * [PHP SDK](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-php-via-opentelemetry.md) * [Ruby SDK](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-ruby-via-opentelemetry.md) * [Splunk](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-splunk-via-opentelemetry.md) * [Sumo Logic](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-sumo-logic-via-opentelemetry.md) * [Tyk](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-tyk-via-opentelemetry.md) * [VMware](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-vmware-via-opentelemetry.md) --- # Using Webhooks > Webhooks connect APIContext to external systems, pushing data and alerts to a service when a condition you set is met. Source: https://docs.apicontext.com/guides/alerting/using-webhooks ## Key Concepts A webhook is a mechanism for connecting systems together simply. Webhooks can be used to link APImetrics to management and other systems so that data and alerts can easily be pushed to the external systems from APImetrics. For most webhooks, you will need to enter a key or some other information that is provided to you by the service associated with the webhook. When a condition you set is met within APImetrics, a message will be generated that is pushed to the service by the webhook. ## Supported Webhooks APImetrics supports the following services: * Generic * Axiom (OpenTelemetry API) * Email * Email (plain text) * Email (template) * BigPanda * Datadog (sends every result through a Datadog integration on your Organization; see [Export to Datadog](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-datadog.md)) * DataDog Metric and Datadog Event (legacy) * Flowdock * HipChat * Hydrolix * Microsoft Teams * New Relic * OpenTelemetry * OpsGenie * PagerDuty * Slack * StatusPage * VictorOps If you don't see the service you need in that list, please [contact support](https://apicontext.com/support). It is usually quick and easy for us to add a new webhook. ## Alerts & Webhooks Page You can use webhooks to create alerts for all your APIs or for particular APIs. In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)) to open the page where you create and edit alerts for all your APIs. ![Alerts and Webhooks page header with the Add new alert and Add new action buttons](https://docs.apicontext.com/img/afeaf3f-image.webp) If you have already created alerts, these will be shown on this page and you can edit the alerts by expanding your desired alert. ![Alerts list showing Email, Datadog, and Microsoft Teams webhooks with their trigger conditions](https://docs.apicontext.com/img/3733178-image.webp) ## Add a New Webhook Click on the **+Add New Alert** button. ![Alerts list with the Add new alert button highlighted](https://docs.apicontext.com/img/a72dd6b-image.webp) From the dropdown, choose the type of webhook you want to create. ![New alert with the Type dropdown open listing webhook options such as Email and Axiom](https://docs.apicontext.com/img/c415592-image.webp) Enter a name for the alert. The alert will automatically be Active but this can be toggled on and off without removing the alert. From the Trigger alerts options, toggle the conditions you want to trigger the alert. The conditions are Pass, Slow, Warning, & Fail. By default, Slow, Warning, and Fail are enabled. ![Alert Settings with the Trigger alerts toggles for Pass, Slow, Warning, and Fail highlighted](https://docs.apicontext.com/img/3fcb9df-image.webp) Enter the details needed for your alert. For this example, it is an email address. APImetrics will automatically populate with email addresses linked to the project so a dropdown will appear and select which should receive the alert. Save your alert. If you have enabled it, it will now be active and alerts will start appearing through the relevant webhook when the trigger conditions are met. ### Snoozing Alerts If you are aware of maintenance or have known issues with your service and want to snooze your alerts, you can simply do this by selecting the desired length of time from the right-hand side. ![Email webhook with the Snooze options for 6, 12, and 24 hours highlighted on the right](https://docs.apicontext.com/img/1d3de10-image.webp) After the allotted time, the alerts will begin again. --- # Export with OpenTelemetry > Send monitoring results to any OpenTelemetry platform by creating an OpenTelemetry webhook in APIContext with your platform's URL and HTTP headers. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-with-opentelemetry Our OpenTelemetry Webhook allows you to send your API monitoring data to any platform that supports OpenTelemetry, such as [AWS](https://aws-otel.github.io/), [Azure](https://docs.microsoft.com/azure/azure-monitor/app/opentelemetry-overview), [Datadog](https://docs.datadoghq.com/opentelemetry/), & [Splunk](https://docs.splunk.com/Observability/gdi/opentelemetry/opentelemetry.html). APIContext is [OTEL-native](https://apicontext.com/features/alerting). Every monitoring result is an OpenTelemetry trace, ready to export to your existing observability stack. # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) Once saved, monitoring results will be passed to the target application starting from the next test call. For every span and attribute the webhook sends, see the [OpenTelemetry payload reference](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md). --- # Generic Webhook > Use this Webhook to stream your API's Performance metrics & events to any custom downstream systems. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/performance-results-webhook/generic-webhook ## How to Configure the Generic Webhook Start by navigating to your desired project. Choose [Alerts & Webhooks](https://client.apimetrics.io/webhooks) from the left-hand navigation bar. 1. Click the "**+ Add new action**" button. 2. Select **Generic** from the Type dropdown. 3. Enter a clear Name for your webhook (e.g., Generic Performance Events Webhook). ![Add new action](https://docs.apicontext.com/img/2a4af7a8821abcc9402dbfa1b6c51014c3748c13aa44ffc4fe475bfcd657a9d9-Generic_Webhook-1.webp) ## Alert Settings 4. Trigger alerts: Toggle the event types (Pass, Slow, Warning, Fail) you want to send to your downstream system. 5. Tags (Optional): Use the Include tags and Exclude tags fields to filter exactly which APIs should trigger these alerts. 6. Threshold: Set a number for "Only alert after this many failures in a row" to avoid noisy alerting (leave as 0 to alert on every event). ## Configuration 7. URL: Enter the publicly accessible destination URL for your downstream system or service. 8. HTTP Headers (Optional): Add up to three custom headers if required by your receiving system (e.g., Authorization: Bearer [access-token]). Make sure to use the exact "key: value" format. ## Authentication 9. Method: Choose the authentication type your downstream server requires (None, Basic Auth, or Client Certificate). ![Generic-Webhook](https://docs.apicontext.com/img/8efc7e8b0aa1076f1994a10cdc25bc6fe0401519c8e7c5d05f6a1b05c2455651-Generic_Webhook-2.webp) ## Save and Manage 10. Ensure the **Enabled** toggle on the right side of the screen is set to ON, and click **Save**. Note: Once configured, you can edit these settings at any time by clicking on the webhook. You can also use the right-hand panel to temporarily Snooze alerts for 6, 12, or 24 hours, or temporarily disable the webhook entirely without deleting it. --- # Setting Alerts > Alerts notify you when an event occurs on an API you monitor, such as a failed or slow call. Set them per API endpoint or globally. Source: https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks ## Key Concepts An alert is a notification that lets you know that some particular event has occurred with one of the APIs that you are monitoring when the API was called. This might be that the call failed or the response was very slow. For an overview of all [alerting capabilities](https://apicontext.com/features/alerting) including escalation paths and team-specific routing, see the platform site. You can use Conditions to set your own criteria for whether a response is flagged as a warning or an error. For instance, you might want to receive an alert if a required field in the returned payload is empty. You can also alert on a Pass, which is especially useful for negative testing in which you want to be alerted if a call passes. We provide support for the following alert types: * Pass - a monitor has met the pass conditions (by default a HTTP 200) * Warning - a monitor has triggered a warning (by default a 4XX client-side result) * Error - a monitor has triggered an error (by default a 5XX server-side result) * SLA error or warning - the call or part of a workflow has exceeded its expected duration or some other specified Service Level Objective * Slow - the call is outside of an expected parameter Webhooks that have parameters left unset are highlighted as **incomplete** in the webhook list, so you can find and finish them. ## Managing Alerts by API Endpoint or Globally Alerts can be set on an API by API basis or globally for all your APIs. To set an alert for a particular API, click on the Alerts & Webhooks tab of the monitor. Click on the +Add New Alert button to invoke the dialog. ![Alerts and Webhooks page listing configured alerts and actions with an Add new alert button highlighted](https://docs.apicontext.com/img/93f5c05-Alerts_Tab.webp) The alert type can be via email or any of a number of Webhook services. ![Alert configuration with the Type dropdown open showing options like Performance Events and PagerDuty](https://docs.apicontext.com/img/7ef5e66-Add_Type.webp) Alerts can be sent to the following platforms: Axiom, BigPanda, Datadog, Email\*, Flowdock, HipChat, Hydrolix, Microsoft Teams, New Relic, OpenTelemetry, OpsGenie, PagerDuty, Slack, StatusPage, and VictorOps. Many platforms support OpenTelemetry, and we recommend OpenTelemetry as the default alerting mechanism. \*Please note that we do not recommend using email for alerting due to the potential for a high volume of alerts if your application experiences an interruption. Next, choose your trigger alert criteria. This defines when you want the alert to be sent. There are four potential criteria, Pass, Slow, Warning, and Error (as described above). By default, a new alert is Enabled. If you disable the alert, you will not receive alerts even if an alerting criteria is met. ![Alert Settings with the Trigger alerts toggles for Pass, Slow, Warning, and Fail highlighted](https://docs.apicontext.com/img/f8f067d-Alert_Triggers.webp) Enter a name for the alert at the top of the section. Then, decide if you want the alert to trigger immediately when the conditions are met, or to delay the trigger until a specific number of failures have occurred. Often a single failure does not indicate a fundamental problem with the API, and we recommend entering a value of "1" here.. ![Expanded Email alert configuration showing name, type, trigger settings, and recipient email address](https://docs.apicontext.com/img/d94a7e9-Add_Alert.webp) Some integration types will require additional information, including Webhooks and OpenTelemetry integrations. Each service requires slightly different parameters, so review the configuration details and fill out the additional details from the target platform. For example, PagerDuty requires a valid Integration key and severity classifier. Each integration type has integration-specific parameters. ![PagerDuty alert configuration with the Integration key and Severity fields highlighted](https://docs.apicontext.com/img/0ad4cb9-setttings.webp) ## Managing Alerts Globally To set alerts globally, click on the Alerts & Webhooks section of the side navigation and fill in the dialog. By default, you will create alerts for al the APIs in your current project. ![Monitors page with the Alerts and Webhooks link highlighted in the left navigation](https://docs.apicontext.com/img/97f9117-Global_Alerts_Nav.webp) To disable alerts globally, navigate to Organization Settings, then select the Downtimes tab. Change the Allow toggle switch to OFF. \*Please note that this will disable ALL alerts for the organization until the toggle switch is returned to the ON position, and could cause you to miss critical operational alerts. ![Organization Downtimes page with the Alerts and Webhooks Allow toggle highlighted to suppress all alerts](https://docs.apicontext.com/img/72463e9-Org_Downtimes.webp) --- Learn how to create a monitor first: [Monitor your first API](https://docs.apicontext.com/monitor-your-first-api.md). --- # OpenTelemetry payload reference > Every span, log record, and attribute the APIContext OpenTelemetry webhooks send, with types, examples, and when each attribute is present. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference To set up the webhook that sends this payload, see [Export with OpenTelemetry](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-with-opentelemetry.md). The **OpenTelemetry** webhook sends each result to your platform as an OpenTelemetry trace over OTLP/HTTP. A result for one Monitor produces one Monitor span and six timing spans. A result for a Workflow is described in [Workflow spans](#workflow-spans). The **OpenTelemetry (Conformance Events)** webhook sends log records instead, described in [Conformance Events](#conformance-events). The example below is the OTLP JSON form of the Monitor span for one result. The names and types are the ones the exporter sends. The values are illustrative, and the certificate is shortened. ```json { "resourceSpans": [ { "resource": { "attributes": [ { "key": "service.name", "value": { "stringValue": "APImetrics" } } ] }, "scopeSpans": [ { "scope": { "name": "Example API status" }, "spans": [ { "traceId": "8a4439de8699e4a4a5f868d81a000640", "spanId": "dfbc5e6391b72526", "name": "Example API status", "kind": 1, "startTimeUnixNano": "1793525400000000000", "endTimeUnixNano": "1793525400134000000", "attributes": [ { "key": "http.route", "value": { "stringValue": "https://api.example.com/v1/status" } }, { "key": "http.request.method", "value": { "stringValue": "GET" } }, { "key": "url.full", "value": { "stringValue": "https://api.example.com/v1/status" } }, { "key": "http.response.status_code", "value": { "intValue": "200" } }, { "key": "apimetrics_org_id", "value": { "stringValue": "EXAMPLE_ORG_ID" } }, { "key": "apimetrics_project_id", "value": { "stringValue": "EXAMPLE_PROJECT_ID" } }, { "key": "apimetrics_project_name", "value": { "stringValue": "Example Project" } }, { "key": "apimetrics_call_id", "value": { "stringValue": "EXAMPLE_MONITOR_ID" } }, { "key": "apimetrics_call_name", "value": { "stringValue": "Example API status" } }, { "key": "apimetrics_result_id", "value": { "stringValue": "EXAMPLE_RESULT_ID" } }, { "key": "apimetrics_agent_id", "value": { "stringValue": "apimetrics_azurenorwayeast" } }, { "key": "apimetrics_cloud", "value": { "stringValue": "Azure" } }, { "key": "client.address", "value": { "stringValue": "203.0.113.10" } }, { "key": "apimetrics_city", "value": { "stringValue": "Oslo" } }, { "key": "apimetrics_region", "value": { "stringValue": "Oslo" } }, { "key": "apimetrics_country", "value": { "stringValue": "Norway" } }, { "key": "apimetrics_continent", "value": { "stringValue": "Europe" } }, { "key": "apimetrics_latitude", "value": { "doubleValue": 59.9139 } }, { "key": "apimetrics_longitude", "value": { "doubleValue": 10.7522 } }, { "key": "tls.protocol.name", "value": { "stringValue": "TLS" } }, { "key": "tls.protocol.version", "value": { "stringValue": "1.3" } }, { "key": "tls.cipher", "value": { "stringValue": "TLS_AES_128_GCM_SHA256" } }, { "key": "tls.next_protocol", "value": { "stringValue": "h2" } }, { "key": "tls.server.certificate_chain", "value": { "arrayValue": { "values": [ { "stringValue": "-----BEGIN CERTIFICATE-----\nMIIB...\n-----END CERTIFICATE-----" } ] } } }, { "key": "tls.server.issuer", "value": { "stringValue": "CN=Example CA R1,O=Example CA" } }, { "key": "tls.server.subject", "value": { "stringValue": "CN=api.example.com" } }, { "key": "tls.server.not_before", "value": { "stringValue": "2026-09-01T00:00:00+00:00" } }, { "key": "tls.server.not_after", "value": { "stringValue": "2026-11-30T00:00:00+00:00" } }, { "key": "tls.server.hash.md5", "value": { "stringValue": "2F127B4B8170CFA17349669CC5A5D9B5" } }, { "key": "tls.server.hash.sha1", "value": { "stringValue": "A5499D20CD1D03665FE38DFABAE0BEDBEB1F7025" } }, { "key": "tls.server.hash.sha256", "value": { "stringValue": "DE802211979E5AF048501B36DB6D8FDDF2F86E33CF671B770F67094C05A1F587" } } ] } ] } ] } ] } ``` Your platform may display these fields differently, for example by flattening attributes into `key = value` pairs. The attribute names are always the ones listed below. ## Resource and scope | Field | Value | | --- | --- | | `resource.attributes["service.name"]` | `APImetrics`. This is the only resource attribute. | | `scope.name` | The name of the Monitor. For a Workflow span, the name of the Workflow. | ## Span fields | Field | Type | Description | | --- | --- | --- | | `name` | String | The name of the Monitor for the Monitor span. For a timing span, one of the names in [Timing spans](#timing-spans). | | `kind` | Integer | Always `1` (internal). | | `traceId` | String | A unique identifier of the trace to which this span belongs. If the request the Monitor sent includes a W3C `traceparent` header, the Monitor span reuses that trace ID, so it lines up with the trace in the target's own telemetry. Otherwise APIContext generates one. | | `spanId` | String | A unique identifier representing the span. The Monitor span reuses the span ID from the `traceparent` header when there is one. | | `parentSpanId` | String | Optional. A unique identifier representing the parent span of the current span. Timing spans set it to the Monitor span. The Monitor span does not set it. | | `startTimeUnixNano`, `endTimeUnixNano` | String | The start and end of the span, in nanoseconds since the Unix epoch. For the Monitor span these are the start and end of the result. | ## Monitor span attributes Every attribute below is set on the Monitor span, and the six timing spans carry the same attributes. The names are exactly as the exporter sends them. Earlier versions of this page showed a `custom.` prefix on the `apimetrics_` names. The exporter does not add one. | Attribute | Type | Example | Present | Description | | --- | --- | --- | --- | --- | | `http.route` | String | `https://api.example.com/v1/status` | Always | The Monitor URL from the configuration | | `http.request.method` | String | `GET` | Always | The HTTP method | | `url.full` | String | `https://api.example.com/v1/status` | Always | The full URL called by the platform | | `http.response.status_code` | Integer | `200` | Always | The response HTTP code | | `apimetrics_org_id` | String | `EXAMPLE_ORG_ID` | Always | The ID of the Organization that owns the Project | | `apimetrics_project_id` | String | `EXAMPLE_PROJECT_ID` | Always | The ID of the Project that owns the Monitor | | `apimetrics_project_name` | String | `Example Project` | Always | The name of the Project | | `apimetrics_call_id` | String | `EXAMPLE_MONITOR_ID` | Always | The ID of the Monitor | | `apimetrics_call_name` | String | `Example API status` | Always | The name of the Monitor | | `apimetrics_result_id` | String | `EXAMPLE_RESULT_ID` | Always | The ID of this Result | | `apimetrics_agent_id` | String | `apimetrics_azurenorwayeast` | When the node is found | The ID of the node (test location) that made the call | | `apimetrics_cloud` | String | `Azure` | When the node has a value | The cloud from which the call was made | | `client.address` | String | `203.0.113.10` | When the node has a value | The source IP from which the call was made | | `apimetrics_city` | String | `Oslo` | When the node has a value | The city from which the call was made | | `apimetrics_region` | String | `Oslo` | When the node has a value | The region from which the call was made | | `apimetrics_country` | String | `Norway` | When the node has a value | The country from which the call was made | | `apimetrics_continent` | String | `Europe` | When the node has a value | The continent from which the call was made | | `apimetrics_latitude` | Double | `59.9139` | When the node has a value | The latitude from which the call was made | | `apimetrics_longitude` | Double | `10.7522` | When the node has a value | The longitude from which the call was made | | `tls.protocol.name` | String | `TLS` | HTTPS, when TLS details are available | The name of the TLS protocol through which the call was made | | `tls.protocol.version` | String | `1.3` | HTTPS, when TLS details are available | The version of the TLS protocol through which the call was made | | `tls.cipher` | String | `TLS_AES_128_GCM_SHA256` | HTTPS, when TLS details are available | The cipher of the TLS protocol through which the call was made | | `tls.next_protocol` | String | `h2` | HTTPS, when the server negotiated one | The next protocol of the TLS protocol through which the call was made | | `tls.server.certificate_chain` | Array of strings | One PEM certificate per entry | HTTPS, when the full chain is available | The chain of the TLS certificate of the endpoint called | | `tls.server.issuer` | String | `CN=Example CA R1,O=Example CA` | HTTPS, when the certificate is available | The issuer of the TLS certificate of the endpoint called | | `tls.server.subject` | String | `CN=api.example.com` | HTTPS, when the certificate is available | The subject of the TLS certificate of the endpoint called | | `tls.server.not_before` | String | `2026-09-01T00:00:00+00:00` | HTTPS, when the certificate is available | The first valid date of the TLS certificate of the endpoint called, in ISO 8601 format | | `tls.server.not_after` | String | `2026-11-30T00:00:00+00:00` | HTTPS, when the certificate is available | The last valid date of the TLS certificate of the endpoint called, in ISO 8601 format | | `tls.server.hash.md5` | String | `2F127B4B8170CFA17349669CC5A5D9B5` | HTTPS, when the certificate is available | The MD5 hash of the TLS certificate of the endpoint called, in uppercase hexadecimal | | `tls.server.hash.sha1` | String | `A5499D20CD1D03665FE38DFABAE0BEDBEB1F7025` | HTTPS, when the certificate is available | The SHA1 hash of the TLS certificate of the endpoint called, in uppercase hexadecimal | | `tls.server.hash.sha256` | String | `DE802211979E5AF048501B36DB6D8FDDF2F86E33CF671B770F67094C05A1F587` | HTTPS, when the certificate is available | The SHA256 hash of the TLS certificate of the endpoint called, in uppercase hexadecimal | | `tls.client.issuer` | String | Not in the example | Only if the Monitor is configured to use mTLS | The client certificate issuer of the endpoint called | | `tls.client.subject` | String | Not in the example | Only if the Monitor is configured to use mTLS | The client certificate subject of the endpoint called | | `tls.client.not_before` | String | Not in the example | Only if the Monitor is configured to use mTLS | The first valid date of the client certificate of the endpoint called, in ISO 8601 format | | `tls.client.not_after` | String | Not in the example | Only if the Monitor is configured to use mTLS | The last valid date of the client certificate of the endpoint called, in ISO 8601 format | A result with no timing data is not exported. ## Timing spans Each result is split up into the following spans for timing information. Each is a child of the Monitor span, so it has the same trace ID and sets `parentSpanId` to the Monitor span's `spanId`. Each span starts when the one before it ends, and the first starts when the result starts. | Span | Description | | --- | --- | | `dns` | Time taken for DNS lookup | | `connect` | Time taken for network connection | | `tls_handshake` | Time taken for network handshake | | `upload` | Time taken to upload the request | | `processing` | Time taken for the server to process the request (time to first byte) | | `download` | Time taken for the download to complete (time to last byte) | For more information on the OpenTelemetry data model, see the **[OpenTelemetry specification](https://opentelemetry.io/docs/concepts/signals/traces/#span-status)**. ## Workflow spans For a Workflow, nothing is exported as each Monitor finishes. When the last Monitor in the Workflow finishes, the webhook exports one Workflow span and, for each API Monitor result in the Workflow, the Monitor span and timing spans described above. The Workflow span is a separate span in the same export. Monitor spans do not name it as their parent span. The Workflow span is named for the Workflow, starts when the Workflow result starts, and ends when it ends. It has these attributes: | Attribute | Type | Description | | --- | --- | --- | | `apimetrics_org_id` | String | The ID of the Organization that owns the Project | | `apimetrics_project_id` | String | The ID of the Project that owns the Monitor | | `apimetrics_project_name` | String | The name of the Project | | `apimetrics_workflow_id` | String | The ID of the Workflow | | `apimetrics_workflow_name` | String | The name of the Workflow | | `apimetrics_workflow_result_id` | String | The ID of this Workflow result | ## Conformance Events The **OpenTelemetry (Conformance Events)** webhook sends each conformance check result as an OTLP log record over OTLP/HTTP, not as a span. It posts to the URL exactly as you enter it, with the HTTP headers you set. Which results are sent follows the webhook's **Pass** and **Fail** switches. | Field | Value | | --- | --- | | `scope.name` | `conformance` | | `severityText` | `WARN` for a failed check, `INFO` for a passed check | | `severityNumber` | `13` (WARN) for a failed check, `9` (INFO) for a passed check | | `body` | ` conformance check ed`, for example `data conformance check failed` | ### Example log record The example is the OTLP JSON form of one log record for a failed `data` check. It shows the scope and the log record only. The values are illustrative. ```json { "scope": { "name": "conformance" }, "logRecords": [ { "severityNumber": 13, "severityText": "WARN", "body": { "stringValue": "data conformance check failed" }, "attributes": [ { "key": "project_id", "value": { "stringValue": "EXAMPLE_PROJECT_ID" } }, { "key": "timestamp", "value": { "stringValue": "2026-11-08T09:30:00Z" } }, { "key": "category", "value": { "stringValue": "data" } }, { "key": "result", "value": { "stringValue": "fail" } }, { "key": "check_name", "value": { "stringValue": "Status is ok" } }, { "key": "call_id", "value": { "stringValue": "EXAMPLE_MONITOR_ID" } }, { "key": "result_id", "value": { "stringValue": "EXAMPLE_RESULT_ID" } }, { "key": "rule_id", "value": { "stringValue": "EXAMPLE_RULE_ID" } }, { "key": "error", "value": { "stringValue": "Expected value not found" } } ] } ] } ``` ### Log record attributes The attributes are the fields of the conformance result. Like the `apimetrics_` names above, they have no prefix. Every record has these attributes: | Attribute | Type | Description | | --- | --- | --- | | `project_id` | String | The ID of the Project | | `timestamp` | String | The time of the result | | `category` | String | The check category: `data`, `objective`, `specification`, `schema`, `security`, `coverage`, `threshold`, or `network` | | `result` | String | `pass` or `fail` | The other attributes depend on the category. Attributes in the last column are present only on a failed check. | Category | Attributes on every result | Added on a failed check | | --- | --- | --- | | `data` | `check_name`, `call_id`, `result_id` | `error`, `rule_id`, and when set, `parent_rule_id`, `rule_json_path`, `rule_value`, `rule_regex`, `rule_substring_of`, `rule_count`, `source_url`, `json_pointer`, `value` | | `objective` | `call_id`, `http_method`, `url`, `metric`, `comparator`, `value`, `period`, `measured` | None | | `specification` | `oas_id` | `rule_id`, `severity`, and when set, `count`, `description` | | `schema` | `oas_id`, `result_id`, `http_method`, `url` | `keyword`, `schema_path`, `instance_paths` (array of strings), `variance`, `expected`, `message` | | `security` | Failed checks only: `specification`, `result_id`, `http_method`, `url`, `check_category`, `check_id`, `description` | Not applicable | | `coverage` | `check_name`, `metric`, `coverage`, `goal`, `total_calls`, `missing_calls`, `total_endpoints`, `missing_endpoints` (numbers) | `missing_call_ids` (array of strings), and when set, `description` | | `threshold` | `call_id`, `http_method`, `url`, `metric`, `delta`, `period`, `measured` | None | | `network` | `check_name`, `affected_endpoints` (number) | `description`, `domain` | Attributes are strings unless the table says otherwise. --- # Conformance Results Webhook > Receive conformance check results via webhook, with pass/fail severity and detailed check attributes. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/conformance-results-webhook If you'd like to send conformance findings to another platform, you can use our conformance webhooks to receive alerts on monitor results. To set it up, you just need to provide us with a URL that is publicly accessible. This could be something as simple as a AWS Lambda or a Google Cloud function. We use a HTTP POST to send you the following data: ```json severityNumber: WARN | INFO (warning for failures, info for passes) severityText: WARN | INFO body: str: “${category} conformance check ${result}ed" attributes: project_id: string timestamp: string category: str - category name check_name: string call_id: string result_id: string ``` Depending on the type of conformance check, there will be additional information. ## Categories The `category` attribute is one of the following. Security findings are sent only when a check fails; every other category is sent for passes and failures. | `category` | Sent for | |---|---| | `schema` | Schema conformance checks | | `security` | Security conformance checks (failures only) | | `specification` | Checks against your API specification | | `data` | Data conformance checks | | `objective` | Objective checks | | `threshold` | Threshold checks | | `network` | Network conformance checks | | `coverage` | Specification coverage | A `coverage` event also carries `metric`, `coverage`, `goal`, `total_calls`, `missing_calls`, `total_endpoints`, and `missing_endpoints`. When the goal is missed, it adds `missing_call_ids` and may add a `description`. See details on conformance checks here: [Conformance](https://docs.apicontext.com/guides/conformance.md) --- # Export to Akamai API Security > Send API monitor data from APImetrics to Akamai API Security for third-party traffic visibility. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-akamai-api-security Our integration to [Akamai API Security](https://techdocs.akamai.com/cloud-security/docs/api-security-service) sends the entire payload of our monitors. This is useful for adding visibility to Akamai API Security for third party SaaS vendors. ## Add a custom traffic source in Akamai API Security In your Akamai API Security product dashboard, navigate to Integrations, then click **Add Integration**. Fill out the details for a new integration with APIContext. ![Akamai API Security Integrations page listing apicontext traffic sources with their online status and request counts](https://docs.apicontext.com/img/244249084f23383bb41ca34506eabdff1cea9ccb4fff0e8936295a94854db048-Akamai_APISecurity_Integrations_Page.webp) ## Create a new Alert In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new alert, and choose the **Type** as **Akamai API Security**. Next choose when to trigger alerts (we recommend triggering on Pass, Slow, Warning, and Fail in order to maximize coverage and visibility into Akamai API Security). Optionally, choose which API tags to **Include** and **Exclude** from the Webhook. Finally, enter the **Engine URL** for your Akamai API Security instance, and the **Source key**, and **Source index** from the custom traffic integration you created in Akamai API Security. Then click Save on the right side. ![APImetrics Akamai API Security alert editor with Engine URL, Source key and Source index fields to complete](https://docs.apicontext.com/img/22a98e39b24d3b007f9302aa598871004981026dfce3042173d6b3eb64bdde36-Screenshot_2025-05-08_at_16.21.16.webp) --- # Export to Alibaba Cloud via OpenTelemetry > Send data from APImetrics to Alibaba Cloud with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-alibaba-cloud-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Alibaba Cloud](https://www.alibabacloud.com/en/product/tracing-analysis?_p_lc=1). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Email Alerts > Send alerts by email in HTML, plain text, or a template whose subject and body you write, and set how many failed calls trigger an alert. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/email-alerts There are three types of Email alerts. The Email option produces email alerts in HTML. This type of email is more readable in a browser or email program. Email (plain text) option produces email alerts in plain text. This type of email can be easier for some kinds of external systems to ingest. The Email (template) option produces plain text email alerts whose subject and body you write yourself, as described in [Customize the subject and body](#customize-the-subject-and-body). ![Email webhook configuration showing name, type set to Email, trigger toggles, and recipient address field](https://docs.apicontext.com/img/2bbb7fe-image.webp) An email alert sends to the address typed into it, not to a user account, so removing someone from a project does not stop their alert emails. See [Stop APIContext emails when someone leaves your team](https://docs.apicontext.com/guides/projects/remove-a-team-member.md). To prevent a potentially excessive number of email alerts from being generated, you can choose the number of failed calls to an API endpoint after which an alert is sent. ## Customize the subject and body Use the **Email (template)** type when you want to control the text of an alert email, for example to put the Monitor name and HTTP code in the subject line. The subject and body are [Jinja](https://jinja.palletsprojects.com/templates/) templates. APIContext fills them in with the details of the result that triggered the alert. 1. Open [Alerts & Webhooks](https://client.apimetrics.io/webhooks) and select **Add new alert**. 2. Name the alert and set **Type** to **Email (template)**. 3. In **Email**, enter the address that should receive the alert. 4. In **Send email after this many failures in a row**, enter how many failures in a row trigger an email. The default is 1. 5. Edit **Template for subject line** and **Template for email body**. Both are required, and both start with the default text listed in the [Email template reference](https://docs.apicontext.com/guides/alerting/using-webhooks/email-template-reference.md#default-templates). 6. Choose the trigger criteria as for any other alert, then select **Save**. See [Setting alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md). The email is sent as plain text. For the variables a template can use and the default subject line and body, see the [Email template reference](https://docs.apicontext.com/guides/alerting/using-webhooks/email-template-reference.md). If a template has an error, the alert is still sent, but the part that failed to render is replaced with an error message that describes the problem. Check your templates by reading the next alert you receive. --- # Export to AWS via OpenTelemetry > Send your API traffic from APIContext to AWS by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-aws-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [AWS](https://aws.amazon.com/otel/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Email template reference > The variables an Email (template) alert can use, with an example subject line, and the default subject line and body for the template type. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/email-template-reference To write a template for an Email (template) alert, see [Email alerts](https://docs.apicontext.com/guides/alerting/using-webhooks/email-alerts.md#customize-the-subject-and-body). ## Variables you can use A template can use every field of the [Performance Results webhook](https://docs.apicontext.com/guides/alerting/using-webhooks/performance-results-webhook.md) payload as a variable. For example, `{{ result_class }}` is the result class, `{{ http_code }}` is the HTTP status code, and `{{ result_url }}` is the link to the result in the portal. Reach into a nested field with a dot, as in `{{ call_meta.name }}` for the name of the Monitor. The `context` field is a dictionary of extra details about the result. The default body loops over it. For example, this subject line names the Monitor, the HTTP code, and the node that made the call: ```text [{{ result_class }}] {{ call_meta.name }}: HTTP {{ http_code }} from {{ location_id }} ``` ## Default templates The default subject line is `[{{result_class}}]: : {{ call_meta.name }}`, where the portal fills in the application name. The default body is: ```text {{ result }}: HTTP {{ http_code }} {{ http_reason }} Latency: {{ response_time }} ms Size: {{ response_size }} bytes Variables: {% for key, value in context|dictsort -%} - {{ key }}: {% if value is mapping %}...{% else %}{{ value }}{% endif %} {% endfor -%} Result: {{ result_url }} ``` --- # Export to Axiom via OpenTelemetry > Want to send your APImetrics data to your Axiom dashboard? Use our OpenTelemetry Webhook. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-axiom-via-opentelemetry Our Egress Webhook for Axiom allows you to send your API traffic to Axiom, in just a few easy steps. ## Create an Axiom API Key & Dataset Firstly, go to your [Axiom](https://axiom.co/) account and create a new Axiom API Key, see [Axiom’s API key documentation](https://axiom.co/docs/reference/settings). Copy this API Key to be used in the APImetrics UI. Also, you can create a new Dataset for your APImetrics data, following [Axiom’s dataset documentation](https://axiom.co/docs/reference/datasets#create-dataset). ## Add Axiom Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![Older sidebar crop with the Alerts and Webhooks link highlighted](https://docs.apicontext.com/img/9ccbe12-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with an empty alerts list and the Add new alert button highlighted](https://docs.apicontext.com/img/b12e1bf-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **Axiom (OpenTelemetry API)**. ![APImetrics alert editor with the Type dropdown open and Axiom (OpenTelemetry API) highlighted](https://docs.apicontext.com/img/bd59947-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **Axiom API Key** and the **Axiom Dataset** in their fields. ![APImetrics Axiom alert editor highlighting the API Key and Axiom Data Set Name fields to complete](https://docs.apicontext.com/img/139fada-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics Axiom alert editor with API Key and Data Set Name filled in and the Save button highlighted](https://docs.apicontext.com/img/25cba17-image.webp) --- # Run Workflow > Create a custom alert using a Workflow with APIs defined in APImetrics Source: https://docs.apicontext.com/guides/alerting/using-webhooks/run-workflow If the built-in alerting options do not suit your needs, you can use the "Run Workflow" option to call any public API you'd like - by setting up API(s) in a Workflow just like for monitoring. The high level steps are: 1. Create a Workflow for your webhook 2. Add monitors to that Workflow 3. In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)) 4. Add Action (bottom section) 5. Select the Run Workflow type, and select your Workflow There are additional runtime variables set in the workflow that identify the API and workflow that caused the issue. You can use these to build URLs or call the APImetrics API to capture more information. * `ALERT_CALL_ID`: the ID of the APImetrics Call setup * `ALERT_CALL_NAME`: the name of the APImetrics Call setup * `ALERT_CALL_METHOD`: the HTTP method (e.g. GET, POST) configured for the monitor * `ALERT_CALL_URL`: the URL (e.g. '[https://api.example.com]()' ) configured for the monitor * `ALERT_PROJECT_ID`: the ID of the APImetrics Project * `ALERT_PROJECT_NAME`: the name of the APImetrics Project * `ALERT_LOCATION_ID`: the ID of the agent that make the request * `ALERT_RESPONSE_SIZE`: the size in bytes of the response * `ALERT_RESPONSE_TIME`: the total time in milliseconds for the request * `ALERT_RESPONSE_HTTP_CODE`: the HTTP code of the result, e.g. 502 * `ALERT_RESULT`: The specific error code (HTTP\_SERVER\_ERROR for a 500, etc) * `ALERT_RESULT_CLASS`: The class of error (FAIL, WARNING, SLOW, or PASS) * `ALERT_RESULT_ID`: the ID of the API result * `ALERT_WORKFLOW_ID`: the ID of the workflow the monitor was running in (if applicable) * `ALERT_WORKFLOW_RESULT_ID`: the ID of the workflow result that was running (if applicable) Note you can use these in your monitor as either `__ALERT_CALL_ID__` or `%%ALERT_CALL_ID%%` --- # Export to Cisco AppDynamics via OpenTelemetry > Send data from APImetrics to Cisco (App Dynamics) with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-cisco-appdynamics-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Cisco (App Dynamics)](https://www.appdynamics.com/product/opentelemetry). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Slack webhook > How to create a Slack incoming webhook and configure it in APImetrics to push alerts for outcomes such as Slow, Warning, and Fail to a channel. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/slack-webhook Create a Webhook for Slack by following their guide: [https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack) Now in APImetrics: * Go to [Alerts & Webhooks](https://client.apimetrics.io/webhooks): * Create a new webhook, selecting Slack as the type and enter the URL you just generated in the API URI box. * Enter the channel you want to push it to (no # required) * Select the Trigger Alerts for your desired outcomes - usually Slow, Warning, and Fail * Press Save ![Slack alert from the apimetrics.io app reporting a Lyft API call that failed with a warning](https://docs.apicontext.com/img/b845736-IMG_8D30870EADC0-1.webp) Example Slack notification on the mobile client ![Slack alert from the apimetrics.io app reporting a Lyft API call that failed with a warning](https://docs.apicontext.com/img/650a86d-Screen_Shot_2019-06-05_at_8.34.32_PM.webp) Example Slack notification on the desktop client --- # Microsoft Teams webhook > How to create a Microsoft Teams incoming webhook connector and configure it in APImetrics to send alerts for outcomes such as Slow, Warning, and Fail. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/microsoft-teams-webhook To set it up a [Teams webhook](https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/connectors/connectors-using#setting-up-a-custom-incoming-webhook), you need to: * In Microsoft Teams, choose More options (⋯) next to the channel name and then choose Connectors. * Scroll through the list of Connectors to Incoming Webhook, and choose Add. * Enter a name for the webhook, upload an image to associate with data from the webhook, and choose Create. * Copy the webhook to the clipboard and save it. You'll need the webhook URL for sending information to Microsoft Teams. * Choose Done. Now in APImetrics: * Go to [Alerts & Webhooks](https://client.apimetrics.io/webhooks): * Create a new webhook, selecting Microsoft Teams as the type and enter the URL you just generated in the API URI box. * Select the Trigger Alerts for your desired outcomes - usually Slow, Warning, and Fail * Press Save ![Microsoft Teams alert card reporting a failed Equifax API call with HTTP 500 error details](https://docs.apicontext.com/img/8b65054-Screen_Shot_2019-06-05_at_8.16.25_PM.webp) Example webhook output on desktop ![Microsoft Teams alert card reporting a failed Equifax API call with HTTP 500 error details](https://docs.apicontext.com/img/573d739-IMG_8682F434F6CF-1.webp) Example webhook output on mobile client --- # Export to Datadog > Install the APIContext Datadog integration, then add an alert that sends every monitoring result, or only conformance events, to Datadog. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-datadog The platform allows you to send your API traffic to [Datadog](https://docs.datadoghq.com). There are two alert types for Datadog: - **Datadog** sends every monitoring result. See [Send all monitoring results to Datadog](#send-all-monitoring-results-to-datadog). - **Datadog (Conformance Events)** sends conformance check results only. See [Send conformance events to Datadog](#send-conformance-events-to-datadog). Both types send through a Datadog integration on your Organization, so install the integration first. ## Install the APIContext integration from Datadog Within your [Datadog interface](https://app.datadoghq.com/), install the APIContext integration and authorize the application. ## Send all monitoring results to Datadog The **Datadog** type is listed only for a project that belongs to an Organization, and it sends through a Datadog integration on that Organization (see [Org-level integrations](https://docs.apicontext.com/guides/integrations/org-level-integrations.md)). 1. In the sidebar, under **Configure Monitoring**, select [Alerts & Webhooks](https://client.apimetrics.io/webhooks). 2. Click **Add new alert**. 3. Enter a **Name**. 4. In **Type**, under **Performance Events**, choose **Datadog**. 5. In **Integration**, choose your Datadog integration. 6. Under **Trigger alerts**, turn on **Pass**, **Slow**, **Warning**, and **Fail**. With all four on, every result is sent. 7. Optional: use **Include tags** and **Exclude tags** to limit which monitors are sent. 8. Click **Save**. **DataDog Metric** and **Datadog Event** are legacy types. They appear in the list only for a project that already has one. Use **Datadog** for new alerts. ## Send conformance events to Datadog In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks**. ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) Scroll through the list to the Conformance Events section, and choose **Datadog (Conformance Events)**. From here, you can name your new **Datadog Conformance Event**. ![APImetrics alert editor with the Type dropdown open and Datadog (Conformance Events) highlighted](https://docs.apicontext.com/img/1b3002dff272a195d74f98862ee9b2b902c8077ae01886176b6ceb1188bca689-Screenshot_2025-07-02_at_12.01.04.webp) Rename your alert as you wish, and click Save. By default, conformance failures are sent to Datadog. You can also send conformance passes by adjusting the toggle switch. ![APImetrics Datadog Conformance Events alert editor with the Name field and Save button highlighted](https://docs.apicontext.com/img/56f421555a4de3dd8ade45ebdcd422f7f169d067919d1fbbbd296f77a04e3d2a-Screenshot_2025-07-02_at_12.03.43.webp) ## Validation Your data will start flowing to Datadog on the next scheduled conformance check. To trigger a manual conformance check, navigate to the Conformance tab from the left menu. ![APImetrics sidebar with the Conformance tab highlighted for triggering a manual conformance check](https://docs.apicontext.com/img/1fe2bfdee0efef3fbf066af44d100d6488ab6dd7eccd81a209481e30e73e88fb-Screenshot_2025-07-07_at_15.41.11.webp) Once there, click "Evaluate Most Recent Calls" on the bottom right corner of the page. ![APImetrics Conformance page with the Evaluate Most Recent Calls button to trigger a manual conformance check](https://docs.apicontext.com/img/a4f5e9e916fdb2ad25319fb1dd1290735eea3539cb2daac23042f706d7351a13-Screenshot_2025-07-07_at_15.41.17.webp) --- # PagerDuty Integration via Webhooks & API > Send APIContext alerts to PagerDuty through the dedicated integration, to notify on-call responders and create high- or low-urgency incidents. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/pagerduty-webhook ## PagerDuty + APImetrics Integration Benefits * Use PagerDuty to triage and manage escalation of events triggered by issues with APIs identified by APImetrics * Notify on-call responders based on alerts sent from APImetrics * Create high and low urgency incidents based on the severity of the event from APImetrics - i.e. identify a Token Refresh issue from a failure or a performance change ## How it Works APImetrics monitors your critical APIs for functional and performance-impacting issues. This could be straight failures or APIs performing worse that expected. By utilizing our integration to PagerDuty using the PagerDuty API you can use PagerDuty to trigger events and escalations based on what is happening with your APIs and according to the rules you set and manage within PagerDuty. * Identify if a token used by a monitor has failed and needs to be refreshed * Alert on critical types of failure i.e. a series of 5XX errors that are unexpected * Identify unexpected performance changes ## Requirements PagerDuty integrations require Owner or Editor access to a project. ## Support If you need help with this integration, please [contact support](https://apicontext.com/support). ## Integration Walkthrough ### In PagerDuty #### Integrating With a PagerDuty Service 1. From the **Configuration** menu, select **Services**. 2. There are two ways to add an integration to a service: * **If you are adding your integration to an existing service**: Click the **name** of the service you want to add the integration to. Then, select the **Integrations** tab and click the **New Integration** button. * **If you are creating a new service for your integration**: Please read our documentation in section [Configuring Services and Integrations](https://support.pagerduty.com/docs/services-and-integrations#section-configuring-services-and-integrations) and follow the steps outlined in the [Create a New Service](https://support.pagerduty.com/docs/services-and-integrations#section-create-a-new-service) section, selecting ***APImetrics*** as the **Integration Type** in step 4. Continue with the In ***APImetrics*** section (below) once you have finished these steps. 3. Enter an **Integration Name** in the format `monitoring-tool-service-name` (e.g. ***APImetrics***-Shopping-Cart) and select ***APImetrics*** from the Integration Type menu. 4. Click the **Add Integration** button to save your new integration. You will be redirected to the Integrations tab for your service. 5. An **Integration Key** will be generated on this screen. Keep this key saved in a safe place, as it will be used when you configure the integration with ***APImetrics*** in the next section.\ ![PagerDuty integration screen showing the generated Integration Key to copy for use in APImetrics](https://pdpartner.s3.amazonaws.com/ig-template-copy-integration-key.png) ### In APImetrics #### Set PagerDuty Alerts for your entire project We recommend setting your PagerDuty connection from the [Alerts & Webhooks](https://client.apimetrics.io/webhooks) option in the side navigation. This will then apply the PagerDuty settings to ALL your APIs. * Create a new Alert by clicking Add new alert ![New alert form expanded in the project Alerts and Webhooks list, naming the alert and setting trigger conditions](https://docs.apicontext.com/img/d94a7e9-Add_Alert.webp) Give the alert a suitable name. ![Alert Type dropdown open showing options including PagerDuty Events API v2 to select for the integration](https://docs.apicontext.com/img/7ef5e66-Add_Type.webp) In the configuration box * Select the Trigger Alerts for your desired outcomes - either: * all four - Pass, Slow, Warning, and Fail. This means that passing monitors will resolve alerts. * Slow, Warning, Fail - Alerts will not resolve. You want to use PagerDuty's auto-resolve feature. * Select the Severity for the alert you want * Press "Save" > **Custom Component or Group** > > If you want the alerts to have a custom component or group set, use a tag on your monitors - in the format `pagerduty_group:value` or `pagerduty_component:value` ![PagerDuty alert configuration with fields for the Integration Key and Severity level for triggered incidents](https://docs.apicontext.com/img/0ad4cb9-setttings.webp) ## How to Uninstall To remove a PagerDuty integration, delete it from [Alerts & Webhooks](https://client.apimetrics.io/webhooks) and it will be automatically removed from the Project with all configuration deleted. --- # Export to Dynatrace via OpenTelemetry > Send every APIContext monitoring result, or only conformance events, to Dynatrace by adding an OpenTelemetry alert on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-dynatrace Our OpenTelemetry Webhook allows you to send your API traffic to [Dynatrace](https://docs.dynatrace.com/docs/extend-dynatrace/opentelemetry/collector). There is no Dynatrace alert type; use one of the two OpenTelemetry types: - **OpenTelemetry** sends every monitoring result, as traces. See [Send all monitoring results to Dynatrace](#send-all-monitoring-results-to-dynatrace). - **OpenTelemetry (Conformance Events)** sends conformance check results only, as logs. See [Send conformance events to Dynatrace](#send-conformance-events-to-dynatrace). To see what arrives in Dynatrace before you set anything up, go to [What you see in Dynatrace](#what-you-see-in-dynatrace). ## Configure Dynatrace to Receive Webhooks from APIContext Generate an Access Token for APIContext in your Dynatrace environment, with the following scopes: "Ingest logs," "Ingest metrics," and "Ingest OpenTelemetry traces." Securely copy the generated access token. ## Send all monitoring results to Dynatrace 1. In the sidebar, under **Configure Monitoring**, select [Alerts & Webhooks](https://client.apimetrics.io/webhooks). 2. Click **Add new alert**. 3. Enter a **Name**, such as "Dynatrace results." 4. In **Type**, under **Performance Events**, choose **OpenTelemetry**. Do not choose **OpenTelemetry (Conformance Events)**, which sends conformance events only. 5. In **URL**, enter the Dynatrace OTLP traces endpoint (replacing `` with your environment ID): `https://.live.dynatrace.com/api/v2/otlp/v1/traces` 6. In **HTTP Header 1**, enter the following header (replacing `` with the access token value copied from Dynatrace): `Authorization: Api-Token ` 7. Under **Trigger alerts**, turn on **Pass**, **Slow**, **Warning**, and **Fail**. With all four on, every result is sent. 8. Optional: use **Include tags** and **Exclude tags** to limit which monitors are sent. 9. Click **Save**. Each result arrives in Dynatrace as an OpenTelemetry trace, starting from the next monitor run. For every span and attribute, see the [OpenTelemetry payload reference](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md). ## Send conformance events to Dynatrace In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks**. ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) Assign a descriptive name to the webhook, such as "Dynatrace Conformance Events."\ Then, select the alert type from the drop down list of "OpenTelemetry (Conformance Events)." ![APImetrics alert named Dynatrace Conformance Events with the Type dropdown open and OpenTelemetry (Conformance Events) highlighted](https://docs.apicontext.com/img/94d08995f993729efc0da7436c34c2ae7c38af5188cf5d37a614db821599e056-Screenshot_2025-07-03_at_14.22.34.webp) In the URL field, enter the following URL (replacing `` with your environment ID): `https://.live.dynatrace.com/api/v2/otlp/v1/logs` In the HTTP Header 1 field, add the following HTTP header (replacing `` with the access token value copied from Dynatrace): `Authorization: Api-Token ` Then click Save to save the new alert. ![APImetrics Dynatrace alert editor with the OTLP logs URL and Authorization HTTP header entered and the Save button highlighted](https://docs.apicontext.com/img/18143cb6e79f55d71de18542b2aca35387fa6e06ae11278754b6c455b86ef12c-Screenshot_2025-07-03_at_14.30.55.webp) ## What you see in Dynatrace APIContext sends results to Dynatrace over OTLP/HTTP, one path for each alert type. The dashed arrows in the diagram are not sent by APIContext: you connect Dynatrace to your own incident tooling in Dynatrace. ![Flow diagram. A monitor run goes through an OpenTelemetry alert and arrives in Dynatrace as traces. Conformance checks go through an OpenTelemetry (Conformance Events) alert and arrive in Dynatrace as logs. Dynatrace can then feed tools you connect there, such as an AIOps or triage tool or ServiceNow.](https://docs.apicontext.com/img/dynatrace-data-flow.svg) | | **OpenTelemetry** alert | **OpenTelemetry (Conformance Events)** alert | | --- | --- | --- | | Arrives in Dynatrace as | Traces | Logs | | One item for each | Monitor result | Conformance check result | | Sent when | The result matches a trigger you turned on: **Pass**, **Slow**, **Warning**, or **Fail** | The check matches a switch you turned on: **Pass** or **Fail** | | Dynatrace endpoint | `/api/v2/otlp/v1/traces` | `/api/v2/otlp/v1/logs` | | Field reference | [Monitor span attributes](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md#monitor-span-attributes) | [Log record attributes](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md#log-record-attributes) | ### A trace for one result Each result is one trace. The Monitor span carries the Monitor's name, and six timing spans sit under it, in the order the request spends its time: ```text Example API status Monitor span, the whole result ├── dns ├── connect ├── tls_handshake ├── upload ├── processing time to first byte └── download time to last byte ``` Every span carries the same attributes, including the Project (`apimetrics_project_name`), the Monitor (`apimetrics_call_name`), the test location (`apimetrics_agent_id`, `apimetrics_country`), the response code (`http.response.status_code`), and, for HTTPS, the TLS details. If the request your Monitor sends includes a W3C `traceparent` header, the Monitor span reuses its trace ID, so the result carries the same trace ID as the API's own telemetry. A Workflow adds one Workflow span to the export. For every span and attribute, see the [OpenTelemetry payload reference](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md). ### A conformance log record Each conformance check result is one log record. This example is a failed `data` check, with attributes flattened into `key = value` pairs. The values are illustrative. ```text scope.name = conformance severityText = WARN severityNumber = 13 body = data conformance check failed category = data result = fail project_id = EXAMPLE_PROJECT_ID timestamp = 2026-11-08T09:30:00Z check_name = Status is ok call_id = EXAMPLE_MONITOR_ID result_id = EXAMPLE_RESULT_ID rule_id = EXAMPLE_RULE_ID error = Expected value not found ``` A passed check has the same shape with `severityText = INFO`, `severityNumber = 9`, and no failure attributes. The attributes depend on the check category: see [Conformance Events](https://docs.apicontext.com/guides/alerting/expanded-alerting/opentelemetry-payload-reference.md#conformance-events). ## Validation Your data will start flowing to Dynatrace on the next scheduled conformance check. To trigger a manual conformance check, navigate to the Conformance tab, and click "Evaluate Most Recent Calls" on the bottom right corner of the page. Then in the Dynatrace portal, open the "Logs" application, and click “Run Query” to view the ingested logs. --- # Export to Docker via OpenTelemetry > Send your API traffic from APIContext to Docker by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-docker-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Docker](https://opentelemetry.io/docs/demo/docker-deployment/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Elastic via OpenTelemetry > Send your API traffic from APIContext to Elastic by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-elastic-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Elastic](https://www.elastic.co/guide/en/observability/current/apm-open-telemetry.html). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to F5 > Configure an OpenTelemetry webhook in APImetrics to export API monitoring traffic and metrics to F5 Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-f5 Our OpenTelemetry Webhook allows you to send your API traffic to F5. # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Fastly CDN via OpenTelemetry > Send data from APImetrics to Fastly CDN with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-fastly-cdn-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Fastly CDN](https://www.fastly.com/blog/opentelemetry-part-1-making-the-edge-less-distant). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Go SDK via OpenTelemetry > Send your API traffic from APIContext to the Go SDK by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-go-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Go SDK](https://opentelemetry.io/docs/languages/go/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Google Cloud Platform via OpenTelemetry > Send data from APImetrics to Google Cloud Platform with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-google-cloud-platform-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Google Cloud Platform](https://github.com/GoogleCloudPlatform/opentelemetry-cloud-run). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Honeycomb via OpenTelemetry > Send your API traffic from APIContext to Honeycomb by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-honeycomb-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Honeycomb](https://www.honeycomb.io/opentelemetry). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Hydrolix via OpenTelemetry > Send your API traffic from APIContext to Hydrolix by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-hydrolix-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Hydrolix](https://hydrolix.io/). # Create Hydrolix Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new alert as **Hydrolix** and choose the **Type** as **Hydrolix**. ![APImetrics alert editor with the Type dropdown open and Hydrolix highlighted](https://docs.apicontext.com/img/c3fe03c6b06701c126c08aac93785559017be1e6455992e09ffd9aafd98232c6-Screenshot_2025-03-21_at_16.13.48.webp) You can now choose which Trigger Alerts and API tags to **Include** and **Exclude** from the Webhook. Typically, you will want to include all Trigger Alerts. To finish the setup, you will need to enter your Hydrolix **URL** as well as the Hydrolix **Username** and **Password**. ![APImetrics Hydrolix alert editor highlighting the URL, Username and Password fields to complete](https://docs.apicontext.com/img/d64855f759018c5499cb330b8adaab85fffa291f9d7059866b1ff10023be106c-Screenshot_2025-03-21_at_16.14.09.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics Hydrolix alert editor with URL, Username and Password filled in and the Save button highlighted](https://docs.apicontext.com/img/5e60df8322abf689755253709706d6941701a1984594bf08073c6240063b9f61-Screenshot_2025-03-21_at_16.18.42.webp) Once saved, monitoring results will be passed to Hydrolix starting from the next test call. Please alert your Hydrolix account team to enable field mapping. The following fields are transferred to Hydrolix: * aRecord: A DNS record for the target endpoint that maps its domain name to its corresponding IPv4 address. * callID: The APIContext identifier for the Call ID - this is a static ID that will be the same every time the call is made. Used for correlating results with the same call parameters. * callURL: URL link to the APIContext Monitor configuration/summary page associated with this Monitor. * city: City from where the call originated, i.e. the location of the APIContext agent. * cloud: Name of the cloud provider from where the call originated, i.e. the location of the APIContext agent. * cnameRecord: A DNS record for the target endpoint that maps its domain name to another domain name, effectively aliasing the domain called to another domain. * connect: The number of milliseconds (ms) to complete the network connection. * contextOwners: APIContext internal reference field used for analysis and de-bugging only. * contextReferences: APIContext internal reference field used for analysis and de-bugging only. * contextViewed: APIContext internal reference field used for analysis and de-bugging only. * continent: Continent where the monitor originated, i.e. the location of the APIContext agent. * country: Country where the monitor originated, i.e. the location of the APIContext agent. * Dns: The number of milliseconds (ms) it took for the DNS lookup. * download: The number of milliseconds (ms) the response download took to complete. * httpCode: The http response code. * 1xx informational response – the request was received, continuing process * 2xx successful – the request was successfully received, understood, and accepted * 3xx redirection – further action needs to be taken in order to complete the request * 4xx client error – the request contains bad syntax or cannot be fulfilled * 5xx server error – the server failed to fulfil an apparently valid request * httpReason: A brief description or phrase associated with an HTTP status code, explaining the reason for the response (e.g., "OK" for a 200 code). * ipAddr: The IP address where the monitor originated, i.e. the location of the APIContext agent. * latitude: The geographic latitude where the monitor originated, i.e. the location of the APIContext agent. * locationID: Unique identifier of the APIContext Node - e.g. apimetrics\_azurenorwayeast. * longitude: The geographic longitude where the monitor originated, i.e. the location of the APIContext agent. * metadataDescription: A textual description providing more information about a specific monitor - this is set during call configuration. * metadataDomain: The domain name of the APIContext monitor - this is set during call configuration. * metadataName: The name of the APIContext monitor - this is set during call configuration. * metadataTags: A list of tags associated with the APIConext Monitor - this is set during call configuration. * nsRecord: A DNS record that specifies the name servers responsible for a particular Monitor.\ processing: The number of milliseconds (ms) the endpoint server took to process the request. * otelTraceparentID: A unique identifier that matches the 'traceParent' header sent in the request. Use this to map the call to your own server logs. * projectMetaName: The APIContext project name where the call configuration can be found. * projectMetaOrg: The APIContext organization name where the project can be found. * projectMetaTags: A list of tags associated with the Project - this is set during project configuration.\ region: The region where the monitor originated, i.e. the location of the APIContext agent. E.g. ‘Oslo’, ‘Dublin’ * responseSize: The size of the response data returned from a request, measured in bytes. * responseTime: The number of milliseconds (ms) the response took to fully download. * resultClass: The result of the test: * PASS: Indicates the call has returned a response code that indicates a PASS condition. Usually, this indicates a 2xx response, but can be set during alert configuration. * SLOW: Indicates the call has returned a response code that indicates a slow response. The expected response time can be set during alert configuration. * FAIL: Indicates the call has returned a response code that indicates a FAIL condition. Usually, this indicates a 4xx or 5xx response, but can be set during alert configuration. * result: The specific status explaining the reason for resultClass in more detail, e.g. ‘Complete’, ‘Skipped’, ‘SLA Warning’, etc. * resultID: A unique identifier assigned to a specific result. This will be unique for every call. * resultURL: This is the URL link that takes you to the APIContext API Results page for this single request. * startTime: The timestamp when the call was instantiated. * targetAsn: The Autonomous System Number (ASN) associated with the target endpoint. * targetCdn: The content delivery network associated with the target endpoint - e.g. CloudFlare, Akamai. * targetCity: The city where the target endpoint is geographically located. * targetCloud: The cloud service provider where the target endpoint is located. * targetContinent: The continent where the target endpoint resides. * targetCountry: The country where the target endpoint or network is geographically located. * targetIPAddr: The IP address of the target endpoint. * targetLatitude: The geographic latitude of the target endpoint. * targetLongitude: The geographic longitude of the target endpoint. * targetNetwork: The network associated with the target endpoint - e.g. CloudFlare, Akamai. * targetRegion: The geographic region where the target endpoint is located. E.g. ‘Oslo’, ‘Dublin’ * tlsHandshake: The number of milliseconds (ms) to complete the network connection. * total: The number of milliseconds (ms) from the initial request until the response is fully downloaded. * upload: The number of milliseconds (ms) the request took to upload to the endpoint server. * workflowId: The APIContext workflow ID associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowName: The name of the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowResultId: A unique identifier for the result of a specific APIContext workflow execution. Please note this will be empty if the request is not part of a workflow. * workflowResultUrl: A URL linking to the APIContext workflow result page for the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowUrl: A URL pointing to the workflow configuration/summary page. Please note this will be empty if the request is not part of a workflow. --- # Export to IBM Instana via OpenTelemetry > Send data from APImetrics to IBM Instana with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-ibm-instana-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [IBM Instana](https://www.ibm.com/products/instana/opentelemetry?mhsrc=ibmsearch_a\&mhq=opentelemetry). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Java SDK via OpenTelemetry > Send API monitoring data from APImetrics to a Java application using the OpenTelemetry SDK. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-java-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Java SDK](https://opentelemetry.io/docs/languages/java/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Logz.io via OpenTelemetry > Send your API traffic from APIContext to Logz.io by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-logzio-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Logiz.io](https://docs.logz.io/docs/shipping/other/opentelemetry-data/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Microsoft Azure Monitor via OpenTelemetry > Send data from APImetrics to Microsoft Azure Monitor with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-microsoft-azure-monitor-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Microsoft Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-enable?tabs=aspnetcore). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Mulesoft via OpenTelemetry > Send your API traffic from APIContext to Mulesoft by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-mulesoft-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Mulesoft](https://docs.mulesoft.com/monitoring/telemetry-exporter). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to New Relic via OpenTelemetry > Send your API traffic from APIContext to New Relic by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-new-relic-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [New Relic](https://docs.newrelic.com/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-introduction/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Nginx via OpenTelemetry > Send your API traffic from APIContext to Nginx by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-nginx-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Nginx](https://docs.nginx.com/nginx/admin-guide/dynamic-modules/opentelemetry/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to NodeJS SDK via OpenTelemetry > Send data from APImetrics to NodeJS SDK with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-nodejs-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [NodeJS SDK](https://opentelemetry.io/docs/languages/js/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to PHP SDK via OpenTelemetry > Send your API traffic from APIContext to the PHP SDK by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-php-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [PHP SDK](https://opentelemetry.io/docs/languages/php/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Ruby SDK via OpenTelemetry > Send your API traffic from APIContext to the Ruby SDK by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-ruby-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Ruby SDK](https://opentelemetry.io/docs/languages/ruby/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to ServiceNow Cloud Observability (formerly Lightstep) via OpenTelemetry > Send API monitoring data from APImetrics to ServiceNow Cloud Observability via OpenTelemetry. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-servicenow-cloud-observability-formerly-lightstep-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Java SDK](https://opentelemetry.io/docs/languages/java/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to Splunk via OpenTelemetry > Send your API traffic from APIContext to Splunk by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-splunk-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Splunk](https://www.splunk.com/en_us/solutions/opentelemetry.html). # Create an OpenTelemetry Webhook Go to the **Configure Monitoring** section in the Left-hand Navigation bar and select **Alerts & Webhooks**. ![Configure Monitoring sidebar section with the Alerts and Webhooks link highlighted](https://docs.apicontext.com/img/6ef80be23c53bb940cd3de3c4df3f304505cf9f3fe1382877f9eb35f316d003d-ETS_01.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert named OTel Splunk Webhook with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/4aa9703db8a46bf838e4f64b598db29562d44de7c2f9c0fb7786104af68d8eeb-ETS_02.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/1a89ccc71f01cea3cba67d658ed493388ee5fb070b78f66f67e6402ba46a605d-ETS_03.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with the URL and HTTP headers filled in, ready to save](https://docs.apicontext.com/img/18c936d61a7cc1a2964b954ab3e83a03a5b26d9311f042936763d1c61c3820fa-ETS_04.webp) --- # Export to Sumo Logic via OpenTelemetry > Send data from APImetrics to Sumo Logic with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-sumo-logic-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Sumo Logic](https://help.sumologic.com/docs/send-data/opentelemetry-collector/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to TrafficPeak via OpenTelemetry > Send data from APImetrics to TrafficPeak with our OpenTelemetry Webhook Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-trafficpeak-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [TrafficPeak](https://www.akamai.com/resources/solution-brief/trafficpeak-observability-platform). # Create TrafficPeak Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new alert **TrafficPeak** and choose the **Type** as **Hydrolix**. ![APImetrics alert named TrafficPeak with the Type dropdown open and Hydrolix highlighted](https://docs.apicontext.com/img/7f3098e409b80b3e4308ed266ff14d331e04b1dc0d28d17191feb28612fe3887-Screenshot_2025-03-21_at_16.28.12.webp) You can now choose which Trigger Alerts and API tags to **Include** and **Exclude** from the Webhook. Typically, you will want to include all Trigger Alerts. To finish the setup, you will need to enter your TrafficPeak **URL** as well as the TrafficPeak **Username** and **Password**. ![APImetrics TrafficPeak alert editor highlighting the URL, Username and Password fields to complete](https://docs.apicontext.com/img/13816de4fcc8dc098ef257b3236c0e38053fa1995ab4cfbdc38c8400b4344f79-Screenshot_2025-03-21_at_16.28.03.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics TrafficPeak alert editor with URL, Username and Password filled in and the Save button highlighted](https://docs.apicontext.com/img/7b7568ce352162a2f84b9018fe337aaa8b74dca92b4c7ffa23e49cf51142568e-Screenshot_2025-03-21_at_16.28.03_copy.webp) Once saved, monitoring results will be passed to TrafficPeak starting from the next test call. Please alert your TrafficPeak account team to enable field mapping. The following fields are transferred to Hydrolix: * aRecord: A DNS record for the target endpoint that maps its domain name to its corresponding IPv4 address. * callID: The APIContext identifier for the Call ID - this is a static ID that will be the same every time the call is made. Used for correlating results with the same call parameters. * callURL: URL link to the APIContext Monitor configuration/summary page associated with this Monitor. * city: City from where the call originated, i.e. the location of the APIContext agent. * cloud: Name of the cloud provider from where the call originated, i.e. the location of the APIContext agent. * cnameRecord: A DNS record for the target endpoint that maps its domain name to another domain name, effectively aliasing the domain called to another domain. * connect: The number of milliseconds (ms) to complete the network connection. * contextOwners: APIContext internal reference field used for analysis and de-bugging only. * contextReferences: APIContext internal reference field used for analysis and de-bugging only. * contextViewed: APIContext internal reference field used for analysis and de-bugging only. * continent: Continent where the monitor originated, i.e. the location of the APIContext agent. * country: Country where the monitor originated, i.e. the location of the APIContext agent. * Dns: The number of milliseconds (ms) it took for the DNS lookup. * download: The number of milliseconds (ms) the response download took to complete. * httpCode: The http response code. * 1xx informational response – the request was received, continuing process * 2xx successful – the request was successfully received, understood, and accepted * 3xx redirection – further action needs to be taken in order to complete the request * 4xx client error – the request contains bad syntax or cannot be fulfilled * 5xx server error – the server failed to fulfil an apparently valid request * httpReason: A brief description or phrase associated with an HTTP status code, explaining the reason for the response (e.g., "OK" for a 200 code). * ipAddr: The IP address where the monitor originated, i.e. the location of the APIContext agent. * latitude: The geographic latitude where the monitor originated, i.e. the location of the APIContext agent. * locationID: Unique identifier of the APIContext Node - e.g. apimetrics\_azurenorwayeast. * longitude: The geographic longitude where the monitor originated, i.e. the location of the APIContext agent. * metadataDescription: A textual description providing more information about a specific monitor - this is set during call configuration. * metadataDomain: The domain name of the APIContext monitor - this is set during call configuration. * metadataName: The name of the APIContext monitor - this is set during call configuration. * metadataTags: A list of tags associated with the APIConext Monitor - this is set during call configuration. * nsRecord: A DNS record that specifies the name servers responsible for a particular Monitor.\ processing: The number of milliseconds (ms) the endpoint server took to process the request. * projectMetaName: The APIContext project name where the call configuration can be found. * projectMetaOrg: The APIContext organization name where the project can be found. * projectMetaTags: A list of tags associated with the Project - this is set during project configuration.\ region: The region where the monitor originated, i.e. the location of the APIContext agent. E.g. ‘Oslo’, ‘Dublin’ * responseSize: The size of the response data returned from a request, measured in bytes. * responseTime: The number of milliseconds (ms) the response took to fully download. * resultClass: The result of the test: * PASS: Indicates the call has returned a response code that indicates a PASS condition. Usually, this indicates a 2xx response, but can be set during alert configuration. * SLOW: Indicates the call has returned a response code that indicates a slow response. The expected response time can be set during alert configuration. * FAIL: Indicates the call has returned a response code that indicates a FAIL condition. Usually, this indicates a 4xx or 5xx response, but can be set during alert configuration. * result: The specific status explaining the reason for resultClass in more detail, e.g. ‘Complete’, ‘Skipped’, ‘SLA Warning’, etc. * resultID: A unique identifier assigned to a specific result. This will be unique for every call. * resultURL: This is the URL link that takes you to the APIContext API Results page for this single request. * startTime: The timestamp when the call was instantiated. * targetAsn: The Autonomous System Number (ASN) associated with the target endpoint. * targetCdn: The content delivery network associated with the target endpoint - e.g. CloudFlare, Akamai. * targetCity: The city where the target endpoint is geographically located. * targetCloud: The cloud service provider where the target endpoint is located. * targetContinent: The continent where the target endpoint resides. * targetCountry: The country where the target endpoint or network is geographically located. * targetIPAddr: The IP address of the target endpoint. * targetLatitude: The geographic latitude of the target endpoint. * targetLongitude: The geographic longitude of the target endpoint. * targetNetwork: The network associated with the target endpoint - e.g. CloudFlare, Akamai. * targetRegion: The geographic region where the target endpoint is located. E.g. ‘Oslo’, ‘Dublin’ * tlsHandshake: The number of milliseconds (ms) to complete the network connection. * total: The number of milliseconds (ms) from the initial request until the response is fully downloaded. * upload: The number of milliseconds (ms) the request took to upload to the endpoint server. * workflowId: The APIContext workflow ID associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowName: The name of the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowResultId: A unique identifier for the result of a specific APIContext workflow execution. Please note this will be empty if the request is not part of a workflow. * workflowResultUrl: A URL linking to the APIContext workflow result page for the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * workflowUrl: A URL pointing to the workflow configuration/summary page. Please note this will be empty if the request is not part of a workflow. --- # Export to Tyk via OpenTelemetry > Send your API traffic from APIContext to Tyk by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-tyk-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [Tyk](https://tyk.io/docs/product-stack/tyk-gateway/advanced-configurations/distributed-tracing/open-telemetry/open-telemetry-overview/). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Export to VMware via OpenTelemetry > Send your API traffic from APIContext to VMware by adding an OpenTelemetry webhook on the Alerts & Webhooks page. Source: https://docs.apicontext.com/guides/alerting/expanded-alerting/export-to-vmware-via-opentelemetry Our OpenTelemetry Webhook allows you to send your API traffic to [VMware](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/11-0/eart/opentelemetry.html). # Create an OpenTelemetry Webhook In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks** ([open it in the platform](https://client.apimetrics.io/webhooks)). ![APImetrics Alerts and Webhooks screen showing the configured alerts and actions for a project](https://docs.apicontext.com/img/4f9ae2f-image.webp) From here, select the **Add new alert** button. ![APImetrics Alerts and Webhooks screen with the Add new alert button highlighted](https://docs.apicontext.com/img/4c96c3b-image.webp) From here, you can name your new **Webhook** and choose the **Type** as **OpenTelemetry**. ![APImetrics alert editor with the Type dropdown open and OpenTelemetry highlighted](https://docs.apicontext.com/img/68e99d7-image.webp) You can now choose which API tags to **Include** and **Exclude** from the Webhook. To finish the setup, you will need to enter the **URL** for your desired platform and all **HTTP Headers** for the platform in their fields. ![APImetrics OpenTelemetry alert editor highlighting the URL and HTTP Header fields to complete](https://docs.apicontext.com/img/da51c10-image.webp) To finalise this Webhook, select the **Save** button and the Webhook will be finished. ![APImetrics OpenTelemetry alert editor with URL and headers filled in and the Save button highlighted](https://docs.apicontext.com/img/7c50a0b-image.webp) --- # Performance Results Webhook > Receive performance monitoring results via webhook, including latency, status codes, and call metadata. Source: https://docs.apicontext.com/guides/alerting/using-webhooks/performance-results-webhook If you'd like to use a custom integration, you can use our Performance Webhooks to receive alerts on monitor results. To set it up, you just need to provide us with a URL that is publicly accessible. This could be something as simple as a AWS Lambda or a Google Cloud function. We use a HTTP POST to send you the following data: ```json { call_id: str call_url: str call_meta: id: str name: str description: str tags: list[str] domain: str project_meta: id: str name: str organization: str tags: list[str] otel_traceparent_id: str result_id: str result_url: str result: str result_class: str location_id: str response_size: int | null response_time: int | null context: dict[str, Any] http_code: int http_reason: str workflow_id: str | null = null workflow_name: str | null = null workflow_result_id: str | null = null workflow_url: str | null = null workflow_result_url: str | null = null start_time: str | null = null target_url: str target_data: [NOTE: may be null] ip_addr: str cloud: str | null = null city: str | null = null region: str | null = null country: str | null = null continent: str | null = null latitude: str | null = null longitude: str | null = null network: str | null = null cdn: str | null = null asn: str | null = null timing_data: [NOTE: may be null] dns: int | null connect: int | null tls_handshake: int | null upload: int | null processing: int | null download: int | null total: int | null location_data: [NOTE: may be null] ip_addr: str cloud: str | null = null city: str | null = null region: str | null = null country: str | null = null continent: str | null = null latitude: str | null = null longitude: str | null = null dns_records: [NOTE: may be null] a: list[str] | null ns: list[str] | null cname: list[str] | null domain_data: age_in_days: int dns_provider: str fqdn: str registrar: str tld: str tls_certificates: list - { expiry: str issuer: { C: str | null = null CN: str | null = null O: str | null = null }, subject: { CN: str | null = null } } ``` Note that the result\_class will be one of PASS, SLOW, WARNING, or FAIL.\ The result is more granular - those can be: * For WARNING class: CONNECTION\_WARNING, HTTP\_REDIRECT\_ERROR, HTTP\_CLIENT\_ERROR, CONTENT\_WARNING, SLA\_WARNING. * For FAIL class: HTTP\_SERVER\_ERROR, CONNECTION\_ERROR, HEADER\_ERROR, CONTENT\_ERROR, SLA\_ERROR. * For PASS class: COMPLETE. * For SLOW class: SLOW\_COMPLETE. Here are the definitions for each field in the webhook: * call\_id: The APIContext identifier for the Call ID - this is a static ID that will be the same every time the call is made. Used for correlating results with the same call parameters. * call\_url: URL link to the APIContext Monitor configuration/summary page associated with this Monitor. * call\_meta: These fields are set during call configuration. * name: The name of the APIContext monitor - this is set during call configuration. * description: A text description providing more information about a specific monitor. * tags: A list of tags associated with the APIConext Monitor. * domain: The domain name of the APIContext monitor. * project\_meta: These fields are set during organization and project configuration. * name: The name of the APIContext monitor. * organization: The APIContext organization name where the project can be found. * tags: A list of tags associated with the Project. * result\_id: A unique identifier assigned to a specific result. This will be unique for every call. * result\_url: This is the URL link that takes you to the APIContext API Results page for this single request. * result: The specific status explaining the reason for result\_class in more detail, e.g. ‘Complete’, ‘Skipped’, ‘SLA Warning’, etc. * For FAIL class: HTTP\_SERVER\_ERROR, CONNECTION\_ERROR, HEADER\_ERROR, CONTENT\_ERROR, SLA\_ERROR. * For PASS class: COMPLETE. * For SLOW class: SLOW\_COMPLETE * For WARNING class: CONNECTION\_WARNING, HTTP\_REDIRECT\_ERROR, HTTP\_CLIENT\_ERROR, CONTENT\_WARNING, SLA\_WARNING. * result\_class: The result of the test. * FAIL: Indicates the call has returned a response code with a FAIL condition. Usually, this indicates a 4xx or 5xx response, but can be set during alert configuration. * PASS: Indicates the call has returned a response code with a PASS condition. Usually, this indicates a 2xx response, but can be set during alert configuration. * SLOW: Indicates the call has returned a response code with a slow response. The expected response time can be set during alert configuration. * WARNING: Indicates the call has returned a response code with a WARNING condition, which can be set during alert configuration. * location\_id: Unique identifier of the APIContext Node - e.g. apimetrics\_azurenorwayeast. * response\_size: The size of the response data returned from a request, measured in bytes. * response\_time: The number of milliseconds (ms) the response took to fully download. * context: APIContext internal reference fields used for analysis and de-bugging only. * http\_code: The http response code. * 1xx informational response – the request was received, continuing process * 2xx successful – the request was successfully received, understood, and accepted * 3xx redirection – further action needs to be taken in order to complete the request * 4xx client error – the request contains bad syntax or cannot be fulfilled * 5xx server error – the server failed to fulfil an apparently valid request * http\_reason: A brief description or phrase associated with an HTTP status code, explaining the reason for the response (e.g., "OK" for a 200 code). * workflow\_id: The APIContext workflow ID associated with the request. Please note this will be empty if the request is not part of a workflow. * workflow\_name: The name of the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * workflow\_result\_id: A unique identifier for the result of a specific APIContext workflow execution. Please note this will be empty if the request is not part of a workflow. * workflow\_url: A URL pointing to the workflow configuration/summary page. Please note this will be empty if the request is not part of a workflow. * workflow\_result\_url: A URL linking to the APIContext workflow result page for the workflow associated with the request. Please note this will be empty if the request is not part of a workflow. * start\_time: The timestamp when the call was instantiated. * target\_data: [NOTE: may be null] * ip\_addr: The IP address of the target endpoint. * cloud: The cloud service provider where the target endpoint is located. * city: The city where the target endpoint is geographically located. * region: The geographic region where the target endpoint is located. E.g. ‘Oslo’, ‘Dublin’ * country: The country where the target endpoint or network is geographically located. * continent: The continent where the target endpoint resides. * latitude: The geographic latitude of the target endpoint. * longitude: The geographic longitude of the target endpoint. * network: The network associated with the target endpoint - e.g. CloudFlare, Akamai. * cdn: The content delivery network associated with the target endpoint - e.g. CloudFlare, Akamai. * asn: The Autonomous System Number (ASN) associated with the target endpoint. * timing\_data: [NOTE: may be null] * dns: The number of milliseconds (ms) it took for the DNS lookup. * connect: The number of milliseconds (ms) to complete the network connection. * tls\_handshake: The number of milliseconds (ms) to complete the network connection. * upload: The number of milliseconds (ms) the request took to upload to the endpoint server. * processing: The number of milliseconds (ms) the endpoint server took to process the request. * download: The number of milliseconds (ms) the response download took to complete. * total: The number of milliseconds (ms) from the initial request until the response is fully downloaded. * location\_data: [NOTE: may be null] * ip\_addr: The IP address where the monitor originated, i.e. the location of the APIContext agent. * cloud: Name of the cloud provider from where the call originated, i.e. the location of the APIContext agent. * city: City from where the call originated, i.e. the location of the APIContext agent. * region: The region where the monitor originated, i.e. the location of the APIContext agent. E.g. ‘Oslo’, ‘Dublin’ * country: Country where the monitor originated, i.e. the location of the APIContext agent. * continent: Continent where the monitor originated, i.e. the location of the APIContext agent. * latitude: The geographic latitude where the monitor originated, i.e. the location of the APIContext agent. * longitude: The geographic longitude where the monitor originated, i.e. the location of the APIContext agent. * dns\_records: [NOTE: may be null] * a: The DNS A record record for the target endpoint that maps its domain name to its corresponding IPv4 address. * ns: The DNS NS record that specifies the name servers responsible for a particular Monitor. * cname: The DNS C Name record for the target endpoint that maps its domain name to another domain name, effectively aliasing the domain called to another domain. --- # Issue Details > Want to dive deeper from the Summary page? Issue Details will give you all the information you need for remediation Source: https://docs.apicontext.com/guides/conformance/issue-details The Issue Details tab can be navigated to from the Summary page by changing the tab at the top of the page. ![Conformance page tab bar with the Issue Details tab selected between Summary and Settings](https://docs.apicontext.com/img/48df6fc5061c52714737412676f454ccbc12233a92a55026155ed1370a0c3d19-image.webp) ## Reading Results The results will be shown in a table with each row being a check completed by APImetrics. ![Unresolved Issues table on the Issue Details page with columns for first seen, resource, operation, check, variance and resolution](https://docs.apicontext.com/img/4f992dd2eced760161896b3111efcc33cad856ab82260ba8e6fba00fe9ccf6b6-Screenshot_2024-08-30_at_16.32.07.webp) Above the table, you can choose which columns to view. All are automatically shown, except the ID column and the Category from the previous page. Each column gives various information to quickly inform you of the outcome of the checks. 1. Last Seen - when the issue was last seen by APImetrics. 2. Server - the server the monitor is going to, the domain. 3. Operation - the HTTP method being used and the endpoint for the monitor. 4. Check - the check that was performed, such as Schema or Authentication Token. 5. Variance - the issue identified by APImetrics such as an invalid value or a missing header. 6. Resolution - the current resolution status for this issue. This is automatically set to Open. Below the **Unresolved Issues** table, there is the **Show Previously Resolved Issues** button. Selecting this will open another table of all the **Resolved Issues**. ![Issue Details page with the Show Previously Resolved Issues button highlighted below the table](https://docs.apicontext.com/img/ed80842769592084f07efbaef17272579274d6f8878491e8a8a5e8718945feb1-image.webp) ![Issue Details page with a second Resolved Issues table revealed below the Unresolved Issues table](https://docs.apicontext.com/img/aa384ec1b4fc65a75bc9e83fe9438bc57f7dd299d2cbc0719c902eee607dd914-Screenshot_2024-08-30_at_16.33.32.webp) This table can be hidden again by selecting the same button which now shows **Hide Previously Resolved Results**. Each row can also be expanded to show more information about the issue. ![Expanded Conformance Issue Details panel showing first seen, resource, check, variance and a notes field](https://docs.apicontext.com/img/c607f7bf1728e2446b53acd71ca44d3536245a51a4ddeaa021785727f2cf9031-Screenshot_2024-08-30_at_16.34.11.webp) ### Expanded Options When any row is expanded, you can add any notes to each issue for ease of communication between different team members. ![Conformance Issue Details panel with the Notes field and Save button highlighted for adding a note to an issue](https://docs.apicontext.com/img/51dbe060c35cd964bcfc1e92e7709aee0b3b4709521a1a523095501a61d60711-image.webp) Remember to select **Save** once you have added your Notes to ensure they are retained. For Security checks, such as Authentication Token checks, you will be able to change the **Endpoint classification** in case it has been misclassified by selecting the correct one from the dropdown. ![Expanded Authentication Token issue showing the Endpoint classification dropdown set to Resource](https://docs.apicontext.com/img/a1068cb-image.webp) ![Endpoint classification dropdown open with Token, Authorization and Resource options](https://docs.apicontext.com/img/e77658a-Screenshot_2024-03-29_at_17.35.10.webp) ## Resolution Status There are four different options for the **Resolution Status**: * Open - a new issue will automatically be set as Open. This will keep it in the **Unresolved Issues** table and is intended to signal that this issue has not been looked at yet. * Acknowledged - this will keep this issue in the **Unresolved Issues** table and is intended to signal that this issue has been noted and is being worked on. * Muted - this will move this issue into the **Resolved Issues** table and is intended to signal that this issue has been acknowledged but is not of any concern. Even if the source changes, the system will not create a new non-conformance finding. Note: this will still show as a failure in the overall Conformance checks. * Resolved - this will move this issue into the **Resolved Issues** table and is intended to signal this issue has been acknowledged and changes have been made to make it conformant. ![Resolution status dropdown options for a conformance issue](https://docs.apicontext.com/img/461c186-Screenshot_2024-03-29_at_17.38.38.webp) ## Update Several Issues at Once Use Edit Mode to change the resolution of many issues in one save. You need the Owner, Editor, or Analyst role on the Project. 1. Open [Issue Details](https://client.apimetrics.io/governance/conformance/results). 2. Select **Edit Mode** above the table, next to the column picker. A checkbox appears at the start of each row, and **Select All** and **Save** buttons appear. 3. Tick the issues you want to update, or select **Select All** to tick every row on the current page. Select **Deselect All** to clear the selection. When two or more rows are ticked, a **Bulk edit mode** badge shows how many rows are selected. 4. In the **Resolution** column of one of the ticked rows, choose the new status. Every ticked row changes to that status in the table. The options are the ones described in [Resolution Status](#resolution-status). 5. Select **Save**. The **Update Conformance Issues** window asks whether you want to update the number of issues you selected. Select **Save Changes**. A progress bar shows how many issues have been updated. When it finishes, Edit Mode closes and the selection clears. Select **Cancel** in place of **Edit Mode** at any point before you save to leave Edit Mode and discard the change. A bulk update changes only the resolution. Each issue keeps its existing note. If an update fails for an issue, that issue keeps its previous resolution. ## Data issues from an MCP step baseline A **Data** issue raised by a check that was created from an MCP result shows a **Baseline** row with the date the check was derived and how many paths it ignores. If the change is expected, click **Accept as Expected** to derive the check again from this result and resolve the issue. See [Set an MCP step's result as expected](https://docs.apicontext.com/guides/conformance/mcp-step-baselines.md#accept-a-change-as-expected). --- # Monitoring Coverage > Ensure your projects have sufficient API and Endpoint monitoring in place with Coverage Checks. Source: https://docs.apicontext.com/guides/conformance/monitoring-coverage > **Tip** > > Monitoring coverage shows how much of your OpenAPI spec is actively monitored. APIContext's [Build to Specifications](https://apicontext.com/features/build-to-specifications) feature goes further, continuously comparing production responses against spec definitions and routing variances to the right team. Monitoring Coverage is a Conformance setting that tracks what percentage of your configured Monitors and unique server endpoints are actively being monitored by APImetrics. The higher the coverage percentage, the more complete your monitoring, ensuring issues are caught across your full API surface, not just a subset of it. Coverage is computed against the API surface defined by the OpenAPI specification attached to the project. The specification establishes the expected set of endpoints, and coverage gating fails Conformance when the monitored portion falls below your thresholds. For how to upload, select, and maintain that specification, see [Manage OpenAPI Specifications](https://docs.apicontext.com/guides/conformance/manage-openapi-specifications.md). ## Monitor Coverage vs. Endpoint Coverage APImetrics distinguishes between two types of coverage: * **Monitor Coverage** refers to the percentage of Monitors configured in your project that are currently being monitored. * **Endpoint Coverage** refers to the percentage of unique server endpoints, defined by their method, host, and path that are being monitored. Since a single endpoint can be called from multiple Monitors within a project, endpoint coverage gives you a distinct view of how much of your actual API surface area is covered. *** ## Enabling Monitoring Coverage Checks To configure Monitoring Coverage for a project: 1. From the left-hand navigation, select **Conformance**. 2. Go to the **Settings** tab. 3. Scroll down to the **Manage Monitoring Coverage** section. 4. Toggle **Enable Coverage Checks** to ON. 5. Enter your desired threshold percentages for **Monitor Coverage** and **Endpoint Coverage**. 6. Click **Save**. ![Conformance-Monitoring_Coverage](https://docs.apicontext.com/img/e2b6cfd4deccc2773eaec5408da6931f48956a391991ab22bc251c3e7930868b-Monitoring_Coverage.webp) > Coverage checks apply at the project level. Each project can have its own coverage thresholds configured independently. *** ## Setting Your Coverage Thresholds If all endpoints in your project are being monitored, set both Monitor Coverage and Endpoint Coverage to 100%. Otherwise, enter the values that reflect your project's monitoring configuration. *** ## Not Sure of Your Coverage Percentages? If you're unsure what percentage of your Monitors or endpoints are currently being monitored, the recommended approach is: 1. Leave both **Monitor Coverage** and **Endpoint Coverage** at **100%** (the default values). 2. Run a Conformance check using the **Evaluate Most Recent Calls** button on the Conformance Summary page. 3. The check will likely return a **fail**, but the **Issue Details** tab will display the actual current coverage percentages for your project. 4. Return to **Conformance** > **Settings** > **Manage Monitoring Coverage** and update the **Monitor Coverage** and **Endpoint Coverage** fields with those values. 5. Click **Save**. This approach lets APImetrics surface the real coverage data from your project, so you can set accurate and meaningful thresholds. > For more information on reviewing conformance failures, see [Issue Details](https://docs.apicontext.com/guides/conformance/issue-details.md). --- # Setting up performance SLOs/SLAs and thresholds > The metrics you can use as project SLO and SLA criteria, and the performance change thresholds you can set, in Conformance Settings. Source: https://docs.apicontext.com/guides/conformance/setting-up-performance-slos-slas-and-thresholds ## Key Concepts You can set project-level Service Level Objectives (SLOs), which can also be used to track Service Level Agreements (SLAs). When a monitor sequence does not conform to the SLO thresholds you have defined, the system will trigger [alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md); you'll also see violations in the reporting interface. SLOs can be created based on the timing of the whole monitor, or based on the timing for a single component of the call. You can set SLOs and receive alerts based on the following metrics (individually or in combination): * Overall availability rate (as a percent of all monitors run) * Overall pass rate (as a percent of all monitors run) * Overall slow rate (as a percent of all monitors run) * Overall warning rate (as a percent of all monitors run) * Overall fail rate (as a percent of all monitors run) * Total latency (in milliseconds) * DNS lookup time (in milliseconds) * TCP connect time (in milliseconds) * SSL handshake time (in milliseconds) * Total network time (in milliseconds) * Upload time (in milliseconds) * Processing time (in milliseconds) * Download time (in milliseconds) * Overall server time (in milliseconds) * CASC quality score (based on score range) * Apdex score (based on score range) ![Conformance Settings page listing Service Level Objective criteria such as availability, slow rate, latency and quality score thresholds](https://docs.apicontext.com/img/d86553fd685369cebd6146a84ea7c0cdf9444776f961c320bc67f653c45ff372-Screenshot_2024-11-15_at_16.07.26.webp) To add, change, or delete SLOs and thresholds, follow the steps in [SLO and SLA Management](https://docs.apicontext.com/guides/slo-management.md). You can also set performance change thresholds, which evaluates changes in various performance components and trigger alerts when those thresholds are exceeded. Thresholds can be set against the following criteria: * **Increase in any latency component** (in milliseconds or percent) * **Decrease in pass / fail grade** (in percentage points) --- For a broader overview of APIContext's SLO/SLA capabilities (including burn-rate alerting, multi-supplier workflow tracing, and regulator-ready evidence), see [SLO/SLA Management](https://apicontext.com/features/api-sla-and-slo-management). --- # Exclude APIs from Conformance checks > Turn on Skip Conformance Checks to stop Schema and Security Conformance checks on a single monitor. Source: https://docs.apicontext.com/guides/conformance/exclude-conformance-monitoring Use this guide when one monitor should not be checked for conformance, for example a helper API or a monitor that is not subject to the same conformance requirements as the rest of your project. The **Skip Conformance Checks** setting turns off Schema and Security conformance checks for that monitor. To exclude a monitor from Schema and Security Conformance checks: 1. **Open the monitor:** In [Monitors](https://client.apimetrics.io/tests/), select the monitor to open its **Edit Monitor** page. 2. **Open the Advanced tab:** Click the **Advanced** tab and scroll to **Advanced features**. 3. **Turn on Skip Conformance Checks:** Switch on **Skip Conformance Checks**. The setting reads: "Do not perform Conformance checks on this Monitor's results." 4. **Save your changes:** Click **Save**. > **Always in not monitored list is a different setting** > > **Always in not monitored list**, under **Home page behavior**, is not the setting for conformance checks. It removes the monitor from the **Monitors in Schedules** table on the Project Overview. To learn what it does, see [Remove a monitor from the monitored list](https://docs.apicontext.com/guides/quality-analytics/omit-from-casc-score.md). ## Clear Conformance errors To clear Conformance errors associated with the excluded APIs, follow these steps: * **Locate the issue:** Locate the specific conformance failure in the "[Issue Details](https://client.apimetrics.io/governance/conformance/results)" section. * **Mark as resolved:** Select "Resolved" from the "Resolution" column for the relevant check. ![Conformance_IssueDetails_Resolved](https://docs.apicontext.com/img/fab44dbbbb92e757c86477a3314f3104d4ecfc9308ea897234eb4f5861e05ea0-Conformance_IssueDetails_Resolution.webp) * **Refresh data:** Click the "Refresh Data" button at the bottom of the list to update the status. ## Next steps - [Conformance explained](https://docs.apicontext.com/concepts/conformance-explained.md): how conformance checks work. - [Conformance](https://docs.apicontext.com/guides/conformance.md): the Conformance Summary and Issue Details pages. --- # Manage OpenAPI Specifications > Upload, select, and maintain the OpenAPI specifications that APImetrics uses for schema conformance and coverage gating. Source: https://docs.apicontext.com/guides/conformance/manage-openapi-specifications APImetrics evaluates your APIs against the OpenAPI Specification (OAS) documents you provide. The specification you attach to a project defines the contract (the operations, request/response schemas, and server endpoints) that Conformance checks measure your live traffic against. It is also the reference surface used when computing [Monitoring Coverage](https://docs.apicontext.com/guides/conformance/monitoring-coverage.md). This page describes how to upload, select, edit, and remove the OpenAPI specifications a project uses. *** ## Where OpenAPI specifications are managed There are two places to add an OpenAPI specification to a project: * **Conformance Settings**: the **Manage OpenAPI Specifications** section, used to attach the specification that Conformance checks evaluate against. * **Catalog**: upload a specification to compare your intended API surface against observed live traffic. See [Catalog](https://docs.apicontext.com/guides/catalog.md) for that workflow. A specification uploaded through either path is stored with the project and can be selected for Conformance checks. You can also upload and view specification files directly from the **Files** section in the sidebar. > Both JSON and YAML OpenAPI documents are supported. > Each specification file is limited to 8 MB. Files over the limit are rejected at upload time, and a previously stored specification over the limit is not processed; it is marked with a processing error instead of being used for conformance or coverage. Very large specifications are usually bundles of many APIs; splitting them into one specification per API keeps each file under the limit and gives clearer per-API conformance results. [Contact support](https://apicontext.com/support) if the limit is a problem for your use case. *** ## Upload an OpenAPI specification from Conformance Settings 1. From the left-hand navigation, select **Conformance**. 2. Go to the **Settings** tab. 3. Scroll to the **Manage OpenAPI Specifications** section. 4. Choose the option to add a specification, then select your **JSON or YAML** file. 5. Upload the file. Once processed, the specification appears in the list of specifications available to the project. If a project has no OpenAPI specification attached, the Conformance Summary page prompts you to upload one before schema conformance can be evaluated. *** ## Select the specification used for conformance Once one or more specifications are attached to the project, select the one you want Conformance checks to evaluate against in the **Manage OpenAPI Specifications** section of **Conformance** > **Settings**. APImetrics runs schema conformance and coverage checks against the selected specification. *** ## Edit or remove a specification From the **Manage OpenAPI Specifications** section in **Conformance** > **Settings**, you can edit, replace, or delete the specifications attached to a project. Removing the specification that Conformance is currently evaluating against will stop schema and coverage checks until another specification is selected. > Conformance settings, including the attached OpenAPI specification, apply at the project level. Each project maintains its own specifications independently. *** ## How specifications drive coverage gating The endpoints defined in your selected OpenAPI specification establish the *expected* API surface for the project. APImetrics compares the endpoints actually being monitored against that expected surface to compute coverage: * **Endpoint Coverage** is the percentage of the unique server endpoints (identified by method, host, and path) declared in (or observed against) the specification that are currently being monitored. * **Monitor Coverage** is the percentage of the project's configured Monitors that are currently being monitored. When you enable **Coverage Checks** and set threshold percentages, Conformance will *fail* if coverage of the specification's endpoints falls below your thresholds. This is the gating mechanism: an accurate, up-to-date specification is what makes coverage gating meaningful, because the specification defines what "full coverage" means for the project. For the full coverage configuration workflow (enabling checks, setting thresholds, and discovering your current coverage percentages), see [Monitoring Coverage](https://docs.apicontext.com/guides/conformance/monitoring-coverage.md). *** ## Comparing a specification against live traffic To compare the endpoints declared in your specification against the endpoints APImetrics observes from live traffic, surfacing drift between the intended and implemented API, upload the specification in the [Catalog](https://docs.apicontext.com/guides/catalog.md). The Catalog's OpenAPI Coverage view shows which declared endpoints are being exercised and which observed endpoints are not yet in any specification. > For background on what conformance measures, see [Conformance](https://docs.apicontext.com/guides/conformance.md) and [Security profiles](https://docs.apicontext.com/concepts/security-profiles.md). ## See also - [Build to Specifications](https://apicontext.com/features/build-to-specifications): automated OAS comparison on every deploy with variance review and remediation routing - [API Conformance](https://apicontext.com/features/api-conformance): continuous drift detection and audit trails --- # Set an MCP step's result as expected > Mark an MCP monitor step's result as expected so that later results of that step are checked against it, and accept a change as the new expected result. Source: https://docs.apicontext.com/guides/conformance/mcp-step-baselines When an MCP server returns what you expect, for example the right list of tools, you can mark that step's result as expected. APIContext derives a [data check](https://docs.apicontext.com/concepts/conformance-explained.md#data-conformance) from it, and every later result of the same step is checked against it. A difference shows as a **Data** issue on the project's Conformance page. ## Before you start - You need an [MCP monitor](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors.md) with a successful result. - You need edit access to the project. Marking a result as expected also adds a tag to the monitor. ## Mark a step's result as expected 1. Open the MCP monitor's result, then click the step whose result you want to keep. The step opens in a sidebar. 2. In the **Baseline** section, click **Mark as Expected**. 3. In **Check name**, keep the suggested name or enter your own. If a check with that name already exists, it is replaced. 4. Under **Exclude**, choose the parts of the result that are allowed to change. The options depend on the step type. For a **List Tools** step, for example, tool descriptions, parameter descriptions, and the paging cursor are excluded by default, because they can change without the server's behavior changing. 5. To exclude anything else, enter JSON paths in the box, one per line, relative to the step result, for example `$.tools[*].outputSchema`. `[*]` matches every element of a list. 6. Click **Save Check**. The section confirms the saved check, how many paths it excludes, and the tag added to the monitor, in the form `data-baseline:`. The check applies to monitors with that tag, so keep the tag on the monitor. The **Baseline** section appears only on steps that act on the server and returned a result. A step that failed cannot be used as a baseline. ## Accept a change as expected When a server changes on purpose, for example when a tool is added, the next results raise **Data** issues. To make the new result the expected one: 1. On the project's Conformance page, open **Issue Details** and expand the **Data** issue. A check created from a result shows **Baseline** with the date it was derived. 2. Click **Accept as Expected**, then **Accept**. The check is derived again from that result, later results are checked against the new baseline, and the issue is marked resolved. ## Related - [Conformance explained](https://docs.apicontext.com/concepts/conformance-explained.md) - [Issue Details](https://docs.apicontext.com/guides/conformance/issue-details.md) - [MCP monitor configuration reference](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors/configuration-reference.md) --- # Conformance > Need to monitor your conformance with different standards or your own specifications? Use the Conformance feature Source: https://docs.apicontext.com/guides/conformance APImetrics measures [API conformance](https://apicontext.com/features/api-conformance) with tools that allow you to evaluate your APIs. With our Conformance feature, we show you how conformant your APIs are with your chosen API standards and your OpenAPI specification documents, as well as their availability and performance. This ensures your APIs are secure for you and your customers and assesses whether your APIs are conformant or what needs to be improved. To get to the Conformance section, select the **Conformance** option from the sidebar under **Project Home**. ![Conformance Summary page with the Conformance option highlighted in the Project Home sidebar](https://docs.apicontext.com/img/5cff9cdc93ac1898514646722f0a40955aeae85ddced6348b675a14536ab1f2d-image.webp) ## Summary Once configured, APImetrics runs regular conformance checks against your selected API Standard and your uploaded OpenAPI specs. If you already have an OAS uploaded, you can select it for conformance checks on the Conformance Settings page. If you don't, you will be prompted on this page to upload. You can also upload an OAS file using the Files section in the sidebar or via the [Catalog](https://docs.apicontext.com/guides/catalog.md). ![Conformance Summary page showing pass and fail status boxes and a table of conformance checks](https://docs.apicontext.com/img/d534939a4a0e9534c2a511d39da30d4039de2b86c65f2784572613c7b761d19c-Screenshot_2024-08-30_at_16.22.34.webp) To choose a standards profile, run checks on demand, or check the same monitors against another profile, see [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md). At the top of the **Summary** page, four different boxes show whether your Project is passing or failing in the following four categories: Standards, Schema, Availability, and Performance. Selecting the repeat button will then give you the percentage rate of the checks. This gives a quick summary of the current state of the Project. ![Conformance Summary with the Standards, Schema, Availability, Performance and Network status boxes highlighted](https://docs.apicontext.com/img/ef4230ae1e0dd776c4672bbe1d4ae36d01e27d4d4dd1e3f69e9d47047bfeaf03-Screenshot_2024-08-30_at_16.25.28.webp) Underneath, there is a table, each row detailing all the checkpoints in the Standards Profile, all the Schemas, the Performance and the Availability. Each of these rows can be expanded for a brief explanation of what checks are happening and link to the [Issue Details](#issue-details). For more information on all of the issues, you can view the **Issue Details** page. ![Conformance Summary with the table of Standards, Schema, Performance and Availability check rows highlighted](https://docs.apicontext.com/img/fb23c03f19896e7a0956608593f83c55578bf30657e88cbcac4cb9e0b5ed09a5-Screenshot_2024-08-30_at_16.27.13.webp) ### Issue Details ![Issue Details tab listing unresolved conformance issues with resolution status for each](https://docs.apicontext.com/img/d64a0d467d9bff90fcfc1593cfb10fb14f3bdc40e7cd54d17c9eea5cf549311c-Screenshot_2024-08-30_at_16.27.56.webp) The Issue Details tab will show all the issues that have been discovered by APImetrics, allowing for triaging with the Resolution Status and the creation of a remediation plan. ## Settings ![Conformance Settings tab showing Standards Profile selection and Service Level Objective thresholds](https://docs.apicontext.com/img/41a72d54bd248c38b7ae9200a0f465a0c0b97a6ae5ec3912d3aa9e8cdc3ad3e2-Screenshot_2024-08-30_at_16.28.52.webp) From the Settings tab, you will be able to change your Security Profile, update any of your SLO & SLA thresholds, or edit, delete, and add any new OpenAPI specifications. --- For background on what conformance means, see [Conformance explained](https://docs.apicontext.com/concepts/security-profiles.md). See also [Security profiles](https://docs.apicontext.com/concepts/security-profiles.md). --- # Enable a standards profile > Select a standards profile in Conformance Settings, save it, and run your monitors or evaluate recent calls to generate the first conformance results. Source: https://docs.apicontext.com/guides/conformance/enable-a-standards-profile Use this guide to choose the standards profile that a project is checked against, then generate its first conformance results. > **To choose your desired API Standard, go to Conformance Settings and there will be a dropdown with the available Standards Profiles in APIContext. Learn more about the different [Standards Profiles** ## Prerequisites For [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md): - A monitor (or workflow) that exercises the Authorization Code flow with **DPoP**, so the token and resource-server checks have traffic to evaluate. - DPoP proof JWTs and `Authorization` headers present on the monitored requests. - Requests classified correctly by stage; workflows are the easiest way to capture an end-to-end flow. ## Steps 1. Open [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings): in the left sidebar, select **Conformance**, then the **Settings** tab. 2. In the **Manage Standards Profiles** section, select the profile you want: - For [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md), select **FAPI 2.0**. - For [UK Open Banking](https://docs.apicontext.com/guides/conformance/uk-open-banking-conformance.md), select the profile that matches your client authentication: **UK Open Banking (TLS Client Auth)**, **UK Open Banking (Private Key JWT)**, **UK Open Banking v4 (TLS Client Auth)**, or **UK Open Banking v4 (Private Key JWT)**. 3. Click **Save**. 4. Run your monitors (or select **Evaluate Most Recent Calls** on the Conformance Summary) to generate results. You can run conformance checks on demand any time by selecting the **Evaluate Most Recent Calls** button at the bottom of the **Conformance Summary** page. ![Conformance Summary results with the Evaluate Most Recent Calls button highlighted at the bottom of the page](https://docs.apicontext.com/img/e9e9a0963e0b70fd6b03473268ca05f24d982814943ec00cf9e2a774d5e7c55c-Screenshot_2024-08-30_at_16.24.59.webp) ## Result Conformance results appear in **INVESTIGATE → Conformance**. For FAPI 2.0, each row corresponds to a checkpoint described on the [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md) page and can be expanded to see the individual checks and the specification section they map to. For UK Open Banking, each check maps to a specific section of the Open Banking specification, which is linked in the result detail view. For triage workflow, see [Issue Details](https://docs.apicontext.com/guides/conformance/issue-details.md). ## Check the same monitors against another profile A project has one standards profile. The selector in **Manage Standards Profiles** takes a single choice, so picking a different profile replaces the current one. To check the same monitors against another profile, use a second project. [Copy the monitors](https://docs.apicontext.com/guides/projects/copy-or-move-a-monitor.md) into it, then choose the other profile in that project's Conformance Settings. Each project is checked against its own profile. ## Next steps - [Security profiles](https://docs.apicontext.com/concepts/security-profiles.md): the standards that APIContext checks, and what each profile covers. - [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md): the checkpoints behind the FAPI 2.0 results. - [UK Open Banking conformance](https://docs.apicontext.com/guides/conformance/uk-open-banking-conformance.md): what the UK Open Banking profile checks. - [Conformance overview](https://docs.apicontext.com/guides/conformance.md): the Summary, Issue Details, and Settings screens. --- # UK Open Banking Conformance Profile > Monitor and verify UK Open Banking API conformance: security headers, OAuth flows, and response schema checks. Source: https://docs.apicontext.com/guides/conformance/uk-open-banking-conformance > **Note** > > The UK Open Banking conformance profile is available on **CONTRACT tier** accounts only. This profile requires the `uk_open_banking_conformance` entitlement. Contact your account manager to enable it. See [plan availability and pricing](https://apicontext.com/pricing). The **UK Open Banking conformance profile** verifies that your API meets the [UK Open Banking Security Profile](https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2), which is based on Financial-Grade API (FAPI) standards and required for PSD2-compliant Open Banking implementations. ## What it checks | Check | Description | |---|---| | **MTLS or private_key_jwt** | The client authenticates using Mutual TLS or `private_key_jwt` (not `client_secret_basic`) | | **PKCE + state parameter** | Authorization Code flows use PKCE with a `state` parameter | | **`x-fapi-interaction-id` header** | Responses echo the `x-fapi-interaction-id` request header | | **`x-fapi-auth-date` / `x-fapi-customer-ip-address`** | Required headers are present in TPP-originated requests | | **Consent IDs in responses** | Account and payment APIs return consent resource IDs | | **TLS 1.2+** | All connections use TLS 1.2 or higher | | **JARM (JWT Secured Authorization Response Mode)** | Where required by the profile level | To turn the profile on, see [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md), which lists the four UK Open Banking profiles in **Manage Standards Profiles**. ## Relationship to FAPI The FAPI-RW-ID2 (FAPI Read/Write) checks are part of the **UK Open Banking (TLS Client Auth)** and **UK Open Banking (Private Key JWT)** profiles. The v4 profiles do not include them. FAPI-RW-ID2 is not a separate option in **Manage Standards Profiles**. For the current FAPI baseline, see [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md). For where results appear and how to read them, see [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md#result). ## See also - [API Conformance capabilities](https://apicontext.com/features/api-conformance): continuous conformance checking with drift detection and audit trails - [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md) - [Conformance overview](https://docs.apicontext.com/guides/conformance.md) - [FAPI 2.0 profile](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md) --- # Custom Authentication > Set up custom API authentication with manual tokens, OAuth refresh flows, browser-based user auth, and callback handlers Source: https://docs.apicontext.com/guides/advanced-authentication/custom-authentication To handle complex auth scenarios, in the **Create Authentication** panel, set **Authentication Type** to **API key in request / Manual Setup**.\ Then open the auth setting and select **Add New Token**. That allows you to specify which exact headers and parameters to use for each monitor using that token.\ Note you can use variables (e..g. %%VARIABLE%% or **VARIABLE**) in these tokens.\ You can also save values into the token to use as variables.\ We also support an "EXPIRES\_IN" value which will set the expire time to the current time plus the number of seconds of the integer value you specify. This allows us to use refresh token flows to ensure you always have a valid token. ## Saving variables into an Auth Token If you want to save variables into an auth token, first create a monitor that receives the values you need. Then you can use the **Assertions** section of that monitor's **Edit** tab to extract the values. Here is a standard OAuth setup: ![Conditions tab extracting access_token, refresh_token, and expires_in from the response body into variables for a standard OAuth setup](https://docs.apicontext.com/img/65032f6-Screen_Shot_2020-10-19_at_5.32.42_PM.webp) Now in the Webhook tag, you can pick "Save Auth Token" and specify which token to use. Now when this API runs, the variables that are extracted by conditions are saved into the access token. ![Alerts and Webhooks tab with a Save Auth Token webhook configured to store extracted variables into the selected access token](https://docs.apicontext.com/img/3ebc718-Screen_Shot_2020-10-19_at_5.32.56_PM.webp) ## Open Browser instead to handle User auth If you want to use a user auth flow to sign in to get an access token, we can support that from a workflow. Here's a complex user auth flow - the last step is the URL that a user would have to open in the browser: ![Multi-step user auth workflow whose final OAuth Authorize step produces the URL a user opens in the browser to sign in](https://docs.apicontext.com/img/4d3aa7a-Screen_Shot_2020-10-19_at_5.14.27_PM.webp) Here's the monitor itself - note it is set up the same way as a standard call. ![OAuth Authorize monitor config with GET method and parameters such as request, state, redirect_uri, and scope set like a standard call](https://docs.apicontext.com/img/873e346-Screen_Shot_2020-10-19_at_5.14.53_PM.webp) The difference is that it is tagged with apimetrics:browser from the Meta tab. ![Meta tab Tags field showing the apimetrics:browser tag added so the monitor triggers a browser redirect instead of running](https://docs.apicontext.com/img/8f39ad7-Screen_Shot_2020-10-19_at_5.15.17_PM.webp) Now when this is run in a workflow by pressing the "Run Workflow" button, the monitor is skipped, and your browser window will redirect to the required URL with the correct parameters. ![Workflow run results where prior steps passed and the apimetrics:browser-tagged OAuth Authorize step is skipped](https://docs.apicontext.com/img/7a5b4c2-Screen_Shot_2020-10-19_at_5.30.26_PM.webp) Note that you will need to use the Save Auth Token webhook to save your intended Auth token. ## Callback handler In combination with redirecting your browser window to start the auth flow, the callback handler at [https://client.apimetrics.io/tokens/callback](https://client.apimetrics.io/tokens/callback) lets you handle the callback in an auth flow your own way. To open it from the sidebar, select **OAuth Callback Handler** under **Project Settings**.\ The page lists the parameters passed to it in the URL, or in the URL fragment, under **Parameters Received**: ![OAuth Callback Handler page with Parameters Received, Variables to use, and selectors for a workflow to run, an auth setting, and a token to update](https://docs.apicontext.com/img/596283d-Screen_Shot_2020-10-19_at_5.31.56_PM.webp) Under **Variables to use**, select **Add...** to add any variables to pass on. Then choose the workflow to run and, optionally, the auth setting and the token to update, and select **Run Workflow**.\ The workflow will have the variables passed to it. Note that we automatically capitalize the variables, so access\_token will map to **ACCESS\_TOKEN** ![OAuth Callback Handler with a variable named ACCOUNT_ID set to 12345 under Variables to use, ready to pass to the selected workflow](https://docs.apicontext.com/img/d01641d-Screen_Shot_2020-10-19_at_5.32.19_PM.webp) ## Refreshing tokens automatically If your access token expires and supports a means to refresh it, you can use the Refresh Token workflow setting to update your access token when needed. This workflow is triggered if the scheduler tries to run a monitor and it finds the token being used is expired. It will stop and run the workflow to refresh the token before resuming. Using manual auth, choose the workflow in the **Refresh Token Workflow** field of the auth setting: ![Create Authentication panel for an API key in request / Manual Setup setting with the Refresh Token Workflow field highlighted](https://docs.apicontext.com/img/943a4e6-Screen_Shot_2020-10-19_at_5.33.42_PM.webp) Here's an example workflow that refreshes an access token ![OAuth: Refresh token workflow with two steps that sign a JWT and exchange the refresh token for a new access token](https://docs.apicontext.com/img/da89dee-Screen_Shot_2020-10-19_at_5.34.01_PM.webp) Note that we save all the variables from the workflow into the token being refreshed. --- # Handling Mutual TLS > How to add mutual TLS to an auth setting by choosing a certificate from your organization's uploaded certificates in the SSL Certificate field. Source: https://docs.apicontext.com/guides/advanced-authentication/mutual-tls > **Tip** > > Mutual TLS is a core component of [API security monitoring](https://apicontext.com/features/api-security). Once configured, APIContext continuously validates that your mTLS setup works correctly from production, providing audit evidence for compliance teams. In the sidebar, under **Configure Monitoring**, select **Monitor Authentication** ([open it](https://client.apimetrics.io/auth/)), then select **Add new Auth Setting**. When **Authentication Type** is **API key in request / Manual Setup**, the **Create Authentication** panel shows an **SSL Certificate** field. Choose a certificate from your [organization's uploaded certificates](https://docs.apicontext.com/guides/authentication-settings/certificates.md), then select **Save**. ![Create Authentication panel for an API key in request / Manual Setup setting with the SSL Certificate field highlighted](https://docs.apicontext.com/img/3558e19-MTLS_Step_1.webp) --- # Advanced Authentication > Configure advanced API authentication in APImetrics including mutual TLS certificates, JWT signing, and FIPS-compliant key storage Source: https://docs.apicontext.com/guides/advanced-authentication [Advanced Authentication](https://www.youtube.com/watch?v=de8fBGA7nD4) APImetrics covers advanced API authentication scenarios including: * Mutual TLS certificates * JWT signing of authentication ## Security Statement APImetrics also supports storing Signing Certificates in an encrypted FIPS compliant KMS. --- # APImetrics API Overview > Use the APIContext API directly: generate an API key, set up auth settings, and get an access token to create monitors, manage workflows, and access reports. Source: https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api > **Tip** > > The REST API can be used alongside the [CLI](https://docs.apicontext.com/cli.md) and [configuration as code](https://apicontext.com/features/configuration-as-code) to automate monitoring setup in your CI/CD pipeline. ## Key Concepts Anything you can do with the User Interface, you can do via monitor. We also have sample Python code available on GitHub. * Create monitors * Edit existing calls * Create and manage authentication settings * Access reports and statistics * Pass through variables and other items * Create and manage workflows A full list of the monitors with examples can be found in the [API reference](https://docs.apicontext.com/reference/intro.md) section. ## Generate an API Key Under the 'Advanced' options in the navigation, select 'APImetrics API' and generate an API Key. ![APImetrics API link highlighted in the Advanced section of the sidebar](https://docs.apicontext.com/img/17c5170-API_Key.webp "API Key.png") ![APImetrics API key page listing account keys, access levels, and Authorization header usage](https://docs.apicontext.com/img/96155b3-api_key_2.webp "api key 2.png") Once generated the API Key can be used as a parameter or a header item. ```http title="HTTP Header" GET /path HTTP/1.1 Authorization: Bearer API_KEY ``` Replace "API\_KEY" with your actual key. ## Generate Auth Settings To automate the process of adding your `API key` to the [Monitor Authentication](https://client.apimetrics.io/auth/) settings: 1. Click `Generate Auth Settings` in the dialog box that appears when you click on the newly created API key. 2. Click `View generated Authentication Settings` to navigate to the Authentication and Token settings page. ![Dialog with Generate Auth Settings and View generated Authentication Settings links](https://docs.apicontext.com/img/f1231f1c59ed9516325a469b381b69e1f8420f477daee4e8669c7fda5a93e444-GenerateAuthSett.webp) > **Debugging Help** > > Note that when developing using our API, you can also specify a query parameter "debug=1" which will enable pretty-printing of the JSON results. ## Generate an Access Token Use the Client ID and Client Secret (for example, from a [Service Account](https://docs.apicontext.com/guides/projects/create-a-service-account.md)) to generate an OAuth access token: ```bash curl -X POST "https://auth.apimetrics.io/oauth/token" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "", "audience": "https://client.apimetrics.io" }' ``` A successful response will look like this: ```json { "access_token": "", "expires_in": 3600, "token_type": "Bearer" } ``` Use the returned `access_token` as a Bearer token in the `Authorization` header when calling API endpoints: ```http title="HTTP Header" Authorization: Bearer ``` Example API request: ```bash curl -X GET "https://client.apimetrics.io/" \ -H "Accept: application/json" \ -H "Authorization: Bearer " ``` --- # How to Send a GraphQL Query > To set up GraphQL calls, additional configurations need to be made for successful calls Source: https://docs.apicontext.com/guides/advanced-features/graphql-queries When adding a new Monitor using GraphQL, a few additional parameters need to be added so that data can properly be sent from APImetrics. We currently have tutorials for the [GET](https://docs.apicontext.com/guides/add-a-monitor/add-api-call.md) and [POST](https://docs.apicontext.com/guides/add-a-monitor/add-api-call.md) methods. ## GET GraphQL Query To set up a GET GraphQL query in the platform, first go to [Monitors](https://client.apimetrics.io/tests/) under **Configure Monitoring** in the sidebar and click **+ Add New API Call**. In the **Create New API Call** panel, enter your endpoint URL and click **Create and Edit** to open the editor. ![Monitor Edit page with the method and endpoint URL fields highlighted](https://docs.apicontext.com/img/3a35f2b-image.webp) From here, **Name** your query and set your API endpoint and method in **Method**. To add your query, select **Query Parameters** and input `query` as your **Key** and your GraphQL query as the **Value**. ![GET GraphQL monitor editor with query as the Query Parameters key and value](https://docs.apicontext.com/img/87ce2ce-image.webp) Once you've completed this, you can **Save** the query and add it to schedules, workflows, or individually run it. ![Saved monitor editor with the Run Monitor Now and Schedule options highlighted](https://docs.apicontext.com/img/f6abcb7-Screenshot_2023-11-27_at_17.13.59.webp) ## POST GraphQL Query To set up a POST GraphQL query in the platform, first go to [Monitors](https://client.apimetrics.io/tests/) under **Configure Monitoring** in the sidebar and click **+ Add New API Call**. In the **Create New API Call** panel, enter your endpoint URL and click **Create and Edit** to open the editor. ![Monitor Edit page with the method and endpoint URL fields highlighted](https://docs.apicontext.com/img/3a35f2b-image.webp) From here, **Name** your query and set your API endpoint and method in **Method**. APImetrics will automatically add a new **Header** for Content-Type, populated with application/json. Input your GraphQL query as the **Data** in the **Body** box. ![POST GraphQL monitor editor with the JSON Body data field highlighted](https://docs.apicontext.com/img/d942b7b-image.webp) Once you've completed this, you can **Save** the query and add it to schedules, workflows, or individually run it. ![Monitor Edit page with the Run Monitor Now control highlighted to run the query](https://docs.apicontext.com/img/cc3c873-Screenshot_2023-11-27_at_19.07.39.webp) --- # String Handling > Extract and manipulate strings in returned payloads by applying filters to a variable path with the | operator. Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/handling-variables-in-a-workflow ## Key Concepts Within APImetrics, it is possible to use advanced string handling functionality. to extract and manipulate strings in returned payloads. ## String Handling in Returned Content If you need to extract part of a returned value, you may take advantage of some filters that you can apply to a variable path using the | operator. | Variable | Description | Parameters | | --- | --- | --- | | int | Convert value to an integer | NA | | length | Returns the length of a string | NA | | lower | Converts a value to lowercase | NA | | reverse | Reverses a string | NA | | round(precision=0,method='common') | Round the number to a given precision.\ The first parameter specifies the precision (default is 0), the second the rounding method.\ If no method is specified 'common' is used | precision - numerical value\ common - rounds either up for values of greater than or equal to 5 in the last decimal place of the number before rounding or down for values equal to less than 4\ ceiling- always rounds up\ floor - always rounds down | | upper | Converts a string to uppercase | | ## Example: Extracting a URL Assuming a JSON response: ```json { "url": "https://www.example.com/some/path/to/something" } ``` If you wanted to extract the path and make it uppercase, in the **Assertions** section of the monitor's **Edit** tab you would use the following expression: ```text url|replace('https://www.example.com', '')|upper ``` This will give the following result: ```text /SOME/PATH/TO/SOMETHING ``` ## Example: Extract an Element from a URL and Set a Variable > **Scenario** > > The API returns a variable "/abc/def/ghi" and you want to extract the middle part. You want to extract it as path\_to\_var.replace("abc/", "")|replace("/ghi", "") if those values were hard coded. This just removes the abc/ and /ghi parts. To handle this programmatically, use the expression: path\_to\_var.split("/")\[1] or path\_to\_var.split("/").1 Underlying this is a Python string object, which has a split function available that converts it to a list of sub-strings. It is then possibly to get the second item in the list (i.e. position 1). ![Response Body assertions panel with an Extract variable row pulling a value from the formatted JSON response](https://docs.apicontext.com/img/02c15b0-response_body_insert.webp) --- Passing variables between steps is what makes [workflows](https://apicontext.com/features/workflows-and-traces) simulate real business processes. Each step produces a full trace. See [Workflows & Traces](https://apicontext.com/features/workflows-and-traces) for the complete capability overview. --- # Types of variable in APImetrics > The three types of variable in APIContext: global variables for a whole project, environment variables for a group of tests, and workflow variables. Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/key-concepts ## Types of variable > **Global Variables** > > Variables that can be used by all the calls in a particular project. > **Environment Variables** > > Environment variables are specific to a certain group of tests in a project. When you are creating the test you can specify the environment to be used. > **Workflow Variables** > > A variable set within a workflow that will only exist for the duration of the call i.e. an authentication TOKEN is extracted from a POST API and then used in a following monitor within the workflow ## Setting GLOBAL or ENVIRONMENT Variables In the sidebar, under **Project Settings**, select [Environment Variables](https://client.apimetrics.io/account-settings/variables/global). To set a variable for a single run instead, use **Set runtime variables...** in the **Run Monitor Now** menu on the monitor's **Edit** tab. ![Environment Variables page defining name and value pairs for a project](https://docs.apicontext.com/img/be58bc4-environment_variable.webp "environment variable.png") ## Description Within the APImetrics software, an environment variable is a user-defined variable that associates a variable name with a variable. The variable is stored for re-use at various points in the APImetrics software. This saves the user from having to enter the same value multiple times with the risk of making a mistake in entering it and also means that if it is desired to change the value, it will be updated automatically at all the points it is used. Suppose a user wants to fill in a text box with the text “Hi, my name is Davina. My email address is davina@apicontext.com“ Ut may be the case that the user is required to enter her email address (or any other data string) at multiple points in the system. The user can then create a variable email = davina@apicontext.com and enter the following literal text into the text box “Hi, my name is Davina. My email address is: \{\{ email }}“ When the text in the text box is parsed by the system, the value of the variable associated with the name email (davina@apicontext.com) will be inserted into and the result will be “Hi, my name is Davina. My email address is davina@apicontext.com“ If the user changes her email address, it is only necessary to change the value of the variable email and the value will be inserted at all points in the system where the literal string \{\{ email }} is found. *** > **For instructions on storing and retrieving values from API responses using [Global or Environment Variables** --- # Advanced Date and Time Handling > How to use the REST API wrapper for the moment.js library to compute, format, and convert dates and times across timezones within a workflow. Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/advanced-date-and-time-handling If the date and time [system variables](https://docs.apicontext.com/concepts/environment-variables/apimetrics-defined-variables.md) do not meet your needs, you can use our simple REST API wrapper for the popular [momentjs library](https://momentjs.com). > **Use this API as part of a workflow** > > Create a monitor, [extract the result](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-json-content.md) and add it to a workflow with your API to take advantage of this functionality. ## API syntax The API provides a simple JSON interface, using GET requests. The [momentjs library](https://momentjs.com) lets you chain operations together. The key documentation for the functions are available from [http://momentjs.com/docs/#/manipulating/](http://momentjs.com/docs/#/manipulating/) and [http://momentjs.com/docs/#/displaying/](http://momentjs.com/docs/#/displaying/). > **Understand the URL format** > > The underlying node library is exposed by separating each call by a `/` in the path of the URL. Variables passed to the functions are separated by a `~`. ## Simple example The simplest call is [`https://momentjs.api.expert/`](https://momentjs.api.expert/), which returns `{"result":"2018-07-16T18:53:09.563Z"}`, i.e. the current time. ## Getting the date for next week A more practical example would be calling the equivalent of\ `moment.utc().add(7, ‘days’).format()` This is achieved by calling:\ [`https://momentjs.api.expert/utc/add~7~days/format/`](https://momentjs.api.expert/utc/add~7~days/format/)\ which returns: `{"result":"2018-07-23T19:08:52Z"}`. Alternatively, [`https://momentjs.api.expert/utc/add~7~days/format~llll/`](https://momentjs.api.expert/utc/add~7~days/format~llll/)\ will output the same in a human friendly date format:\ `{"result":"Mon, Jul 23, 2018 7:09 PM"}`. ## Timezones The timezone module is also installed, so you create more complex calls:\ [`https://momentjs.api.expert/utc~1980-08-20T15:25Z/tz~America%2FLos_Angeles/locale~fr/format~LLLL%20z/`](https://momentjs.api.expert/utc~1980-08-20T15:25Z/tz~America%2FLos_Angeles/locale~fr/format~LLLL%20z/) which is the same as calling in JavaScript: ``` moment.utc(“1980-08-20T15:25Z”) .tz(“America/Los_Angeles”) .locale(“fr”) .format(“LLLL z”) ``` That example parses a UTC date, converts it to the US West Coast timezone and then changes the locale to French so the format outputs the date in French long-friendly format (`LLLL`) followed by the timezone (`Z`), still in PDT. The output is:\ `{"result":"mercredi 20 août 1980 08:25 PDT"}` > **Note** > > We have to URL-encode the `/` in `America/Los_Angeles` to `%2F` as that is part of the URL syntax. The space character in the format string is also converted to `%20`. --- # JSON: Extracting a variable > Extract and validate values from JSON API responses using dot notation and conditions in APImetrics monitors Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-json-content ## Key Concepts With an API that returns a JSON body, you can use conditions set in the **Assertions** section of the monitor's **Edit** tab to extract results and give them a variable name. You can also set a pass/fail condition that depends on a specific string or result being returned. ## Handling Content Most REST APIs return data in dictionary objects, also known as mappings. They are indicated by \{ "curly braces". To find a value, use the key name to index into the object. > **Example** > > Use a dot (.) to access attributes of a JSON object. Alternatively, subscript syntax (\[]) can be used. The following expressions are equivalent: > > foo.bar\ > foo\['bar'] ## Handling a List Lists, or Arrays are a sequential order of values or objects. In JSON they are indicated by a \[ "square bracket". To find a value, you use the zero-based index of the item in the list. > **Picking the first item in a list** > > If the response is a list, you can access the first item with either of these expressions: > > my\_list\[0]\ > my\_list.0 ## Keys that contain a hyphen A hyphen (`-`) in a key name must be written as `\x2d` in the path. If you type the hyphen itself, the path does not match the key, so the assertion cannot find the value. For example, given this response body: ```json { "data": { "My-Key": "myValue" } } ``` use this path to read `myValue`: ```text data["My\x2dKey"] ``` The same rule applies when the key sits at the root of the response body, with no parent object. For this body: ```json { "My-Key": "myValue" } ``` use this path: ```text ["My\x2dKey"] ``` Only the hyphen needs this encoding. Write the rest of the key as it appears in the response. ## Example: Pick Verify a Specific Word from a JSON body Let us assume we want to verify that the sixth word returned in a result is 'What' and set a pass condition contingent on it being the word having that value. The returned JSON looks like this: ```json { "Recognition": { "Info": { "metrics": { "audioTime": 7.94000006, "audioBytes": 127092 } }, "Status": "OK", "ResponseId": "f160c005a1b78d2abda5eda4aa935a6f", "NBest": [ { "Confidence": 0.39000000000000001, "ResultText": "Hello this is a test. What time is it goodbye.", "LanguageId": "en-US", "Grade": "accept", "Hypothesis": "hello this is a test what time is it goodbye", "Words": [ "Hello", "this", "is", "a", "test.", "What", "time", "is", "it", "goodbye." ] } ] } } ``` To extract the sixth word, we can use either of these constructions: ```text Recognition.NBest.0.Words.5 ``` or ```text Recognition.NBest[0].Words[5] ``` In the Assertions section for the Monitor Edit tab, we would enter the following to create the conditional condition: ![Assertions section with a Response Body assertion checking Recognition.NBest[0].Words[5]](https://docs.apicontext.com/img/3780b59-Screenshot_2024-02-20_at_14.21.14.webp) --- # Advanced Uses in Workspaces > Advanced patterns for scoping environment variables to workspaces and resolving them across objects. Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/variable-use-in-workspaces ## Key Concepts It is possible to define multiple workspaces that have their own associated objects. This allows flexible and powerful handling of variables. ## Example The text to be parsed can belong to an object that can be bound to a workspace. Suppose that we have the following structure **Object\_1**:\ workspace = workspace\_1\ text = “Hi, my name is Davina. My email address is \{\{ email }}, my phone number is\ \{\{ phone }}, my Skype id is \{\{ skype}} and my var 4: \{\{ this.var\_4 | $”VAR\_NOT\_FOUND” }}“ **Object\_2**:\ workspace = workspace\_2\ text = “Hi, my name is Davina. My email address is \{\{ email }}, my phone number is\ \{\{ phone }}, my Skype id is \{\{ skype}} and my var 4: \{\{ this.var\_4 | global.var\_4 | $”VAR\_NOT\_FOUND” }}“\*\* when parsing the above structure, the results should be **Object\_1**:\ text = “Hi, my name is Davina. My email address is davina@apicontext.com, my phone number is\ +44-7123-456789 and my Skype id is davina@apicontext.com and my var\_4: VAR\_NOT\_FOUND” **Object\_2**:\ text = “Hi, my name is Davina. My email address is davina@apicontext.com, my phone number is\ +44-7123-456789 and my Skype id is davina@apicontext.com and my var\_4 value\_4” ## Explanation Object\_1 is bound to workspace\_1 Object\_2 is bound to workspace\_2\ Object 2 belongs to Object 1. Variables associated with Object 2 will be searched for\ in the following workspaces: workspaces\_2, workspace\_1, global. If the workspace of variable is not defined, the parser will search first in workspace\_2. If the\ variable is not defined in workspace\_1, it will search in workspace\_1. If the variable is not defined in workspace\_1, it will search in the global workspace. Object 1: variables associated with Object 2 will be searched for in the following workspaces: workspace\_1, global. This search order in workspaces defines the principle of workspace scopes. To force the parser to search for a variable only in the current object workspace context, a special workspace reserved name this is used in the form this.*var*. With this usage, the user can define the search order as shown in the above example for var\_4. var\_4 is not defined in Object\_2. The alternative is global, and var\_4 is defined in global. global workspace var\_4 is returned. Because var\_4 is not defined in Object\_1, the alternative is text VAR\_NOT\_FOUND is returned. > **Important** > > The global workspace is always the last workspace to be searched in for a variable. --- # XML: Extracting a variable > Parse and extract variables from XML API responses using XPath syntax in APImetrics conditions and workflows Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/parsing-xml-content ## Key Concepts With an API that returns XML content, the XML can be parsed and manipulated, and items extracted from either for a validation check in a specific test or as part of a workflow. ## XPath Syntax Standard XPath syntax is used. | Item | Description | | --- | --- | | tag | Selects all child elements with the given tag. For example, spam selects all child elements named spam, and spam/egg selects all grandchildren named egg in all children named spam. | | * | Selects all child elements. For example, */egg selects all grandchildren named egg. | | . | Selects the current node. This is mostly useful at the beginning of the path to indicate that it is a relative path. | | // | Selects all subelements on all levels beneath the current element. For example, .//egg selects all egg elements in the entire tree. | | .. | Selects the parent element. | | [block:ap | Selects all elements that have the given attribute. | | [block:api-header | Selects all elements for which the given attribute has the given value. The value cannot contain quotes. | | [bloc | Selects all elements that have a child named tag. Only immediate children are supported. | | [block:api-h | Selects all elements that have a child named tag whose complete text content, including descendants, equals the given text. | | [block:api | Selects all elements that are located at the given position. The position can be either an integer (1 is the first position), the expression last() (for the last position) or a position relative to the last position (e.g. last()-1). | > **How the selector works** > > The selector returns the first matching element. After the first element, it treats the rest of the result like it would a JSON structure and anything after the ] is handled by the JSON parser. ## Accessing Element Information The XPath selector will return the first matching XML element. This object is then passed on to the JSON parser as the following object: ``` { 'tag': << element tag >>, 'text': << element textual content >>, 'attrib': << element attributes in a dictionary >> } ``` So, for instance, to obtain the attribute list from the first XML node called slide, 'slide|attire' could be entered. ## Namespaces XML elements must be addressed using a fully qualified tag, so the namespace must be included by using braces `{}`. The namespace must be specified by URI. For example: ``` An example document a simple document Another element ``` Element `e2` can be matched by: `.//{http://me.com/namespaces/foofoo}e2` ## Selecting or Validating a Variable ```xml {/* A SAMPLE set of slides */} {/* TITLE SLIDE */} Wake up to WonderWidgets! ``` './/*\[@date]|tag' will match the slideshow element and return the tag `slideshow`. './/*\[style]|attrib.style' will find the \ element (as it is the only tag with a style attribute) and then after the `|` the attribute `style` is selected. --- # Adding a Unique Call ID for Tracing > How to watermark each call with the RESULT_ID system variable in a header so it can be found in API gateway logs and other tools. Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/adding-a-unique-call-id-for-tracing APImetrics stores all call results and identifies outliers for rapid fault resolution purposes. To support this further, you can add a unique identifier to each instance of a call to make it easier to find in other systems and tools. ## 1. Define a header variable that can be ignored We would typically suggest something simple in the header like X-trace or similar that can be ignored by your backend, but give you something to search for you in your results. ## 2. Add the System Variable Result\_ID In the Header Parameters add: x\_trace = %%RESULT\_ID%% All calls will then be 'watermarked' with a unique ID number. You can see that when you edit the Header and put the %%RESULT\_ID%% in the preview pane shows this as the monitor that will be made. ![API Call Edit with an x_trace header set to %%RESULT_ID%% and the preview pane showing it resolved in the request](https://docs.apicontext.com/img/c972987-adding_variable_trace.webp) ## 3. Finding the Result\_ID When you now look at a result, you will see the unique identifier in the HTTP call data. The identifier will appear in the gateway logs as part of the call data and so can be searched for with API gateway log tools. --- # JSON: advanced features - filtering a list & returning a value > Find an item anywhere in a returned JSON list with a filter, then extract it as a variable, using the Jinja-based filters and tests in assertions. Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/json-advanced-features-filters-and-tests ## Overview You have an item that is returned in a JSON list but rather than being in a specific location in the list i.e. foo.\[2].bar - it could be in any location in the list. Using a filter to identify the item, and then extracting that as a variable is how we handle this scenario. ## Summary The Assertion checks syntax uses a cut-down version of the [Jinja templating library](https://jinja.palletsprojects.com/en/2.10.x/templates/#list-of-builtin-filters) to parse the data, which allows for some filters (marked by `|`) and tests as well as the direct dot-notation syntax. For example, consider the following JSON: ```json { "headers": [ { "key": "Content-Type", "value: "application/json" }, { "key": "Interaction-Id", "value: "123456789123456789" }, { "key": "X-APImetrics-Id", "value": "asdfasdfasdfasdf" } ] } ``` In this JSON, the headers are in a list. If that list is always in the same order, you can use the regular notation to find the value associated with the key Interaction-Id: > `headers[1].value` However, if this list is not in a guaranteed order, you need to use *filters* and *tests* to get the value you require. In the above example, to get the Interaction-Id, you'd use the following assertion: > `headers|selectattr("key", "eq", "Interaction-Id")|map(attribute="value")|first` \ To explain: * the `selectattr` filters the list of header objects where the object has an attribute `key`, that is equal to `Interaction-Id` - this will reduce the headers list to the a list containing the one matching item * the `map` with attribute extracts the value for the filtered list - this will leave a list with one item that is the value we want * the `first` returns the first item in the list For the full list of filters and tests, see the [JSON filters and tests reference](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/json-filters-and-tests-reference.md). ## Use Case In this example, we have a sample returned JSON list where we want to find the Interaction ID and extract that as a variable for use in another call. ![Sample returned JSON with a headers array containing the Interaction-Id key to be filtered and extracted](https://docs.apicontext.com/img/dd3fb70-example_JSON_for_filter_and_extract.webp) The first step is to set up an assertion check to create a filter and check that the item exists. We do this in the 'assertions' section of the API edit pane. ```json json.headers|selectattr("key", "eq", "Interaction-Id")|map(attribute="value")|first ``` We set the ASSERTION to test it exists using the filter string in the test, thus: ![Assert row testing that the Interaction-Id selectattr filter expression exists, else set result to Error](https://docs.apicontext.com/img/baad0a4-assert.webp) We then add the command to EXTRACT the value: First we set the search criteria to find the value Interaction id. ```json json.headers|selectattr("key", "eq", "Interaction-Id")|map(attribute="value")|first ``` And then set the EXTRACT conditions to set the variable you use. ![Extract row saving the filtered Interaction-Id value as the INTERACTION_ID variable](https://docs.apicontext.com/img/775887b-extract.webp) Your assertions section of the edit pane should look something like this: ![Assertions Response Body section showing both the Assert exists check and the Extract to INTERACTION_ID rows](https://docs.apicontext.com/img/18751f3-set_filter_and_extract.webp) When the monitor is run, the variable INTERACTION\_ID is set to the value of the Interaction id in the returned JSON. This can be used in another call in a workflow using %%INTERACTION\_ID%% or **INTERATION\_ID** --- # Use your Signing Key in Workflows > Use this guide to generate the upgraded JWT Signing API call and update your existing workflows accordingly. Source: https://docs.apicontext.com/guides/advanced-features/signing-keys If you’re replacing an existing signing certificate, update your configuration to use the new Upgraded Signing API instead of the older helper API: > Old endpoint: `https://us-central1-viatests.cloudfunctions.net/jwt-kms-signer` > New endpoint: `https://client.apimetrics.io/api/2/jwt/encode` A one-click upgrade option is available to create the new JWT Signing monitor automatically. After it’s created, you will need to manually update your workflows to use this new monitor (see Step 5 below). **Follow the steps below to complete the update:** 1. **Locate the Old Helper API** In your workflows - Click Edit and you will see a "Create Updated Call" button. 2. **Click "Create Updated Call"** - Clicking this button will automatically generate a new JWT signing API endpoint. ![Old Helper API](https://docs.apicontext.com/img/ba43b165a7c9cc7157bfc42b496902e42b2f50e3bbb4efe84338ba7df1453afc-JWT-Signing-API.webp) 3. **Review the New Monitor** - The new JWT Signing monitor will be automatically generated and appear similar to the example below. ![Upgraded JWT SIgning API](https://docs.apicontext.com/img/782258e5ac308ba164bc09b8c7458e2a7461c632b0eaeafc128f5e9451ba78ea-Upgraded-JWT-Signing.webp) 4. **Update the `kid` Parameter** - Set the `kid` parameter to the Key ID of your new certificate. We strongly recommend storing the Key ID in an environment variable to make management easier as shown in the image below. ![Environment Variables](https://docs.apicontext.com/img/327c775ff869cdd7b75ecd8165b3618c3253fc4ad195d62a07faf1dfd189dfcb-Env-Variables.webp) 5. **Update All Workflows** - You must replace all references to your old monitor with the newly created monitor in every workflow where it is used. ![Update_Workflows](https://docs.apicontext.com/img/4726ac3abb13829b38474b8bff1517621bd0e28cfe4bd4f51350f8743d385814-Workflow_Edit.webp) > For more comprehensive details regarding the new JWT Signing API, please refer to the **[JWT Encode API reference](https://docs.apicontext.com/reference/intro.md)**. --- # Examples > Learn how to bind variables to monitor and workflow workspaces with practical examples of URIs, headers, and scope resolution Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/examples ## Key Concepts It is possible to bind objects to workspaces associated with monitors and workflows. This allows flexible and powerful use of variables in monitors and workflows so that users are not limited to fixed values. This opens up the potential to create more dynamic monitors and workflows. ## Monitor and Workflow Workspaces Currently, in the APImetrics software, it is possible to bind two related objects to a workspace: monitor and workflow. Because of the nature of the workflow workspace to force its monitors to run in its environment, the workflow workspace always overrides the Monitor workspace. Variables in Monitor objects are searched for first in the workflow workspace, then in Monitor workspace and lastly in the global workspace. The variable search order (scope) is Work flow workspace\ Monitor workspace\ global workspace\ The global workspace is always the last workspace to be searched for variables. If the workspace of Work flow is global, the order will be Monitor workspaces\ global workspace\ Monitor elements subject to contain variables (and parsed for retrieval): • API URL\ • URI Parameters: name and value\ • Headers: name and value\ • Content: body content\ ◦ text\ ◦ json\ ◦ xml\ ◦ URLEncoded variables: name and value\ • Conditions: Property and Value\ • WebHooks: parameters ## Example: Set a URI as a Variable In this example we will set a variable to be the root URI for monitors and show it used in an example. Firstly, we set the variable test\_uri\_1 ![Environment Variables page defining project variables by Name and Value, such as callUrl and petId](https://docs.apicontext.com/img/292a428-setting_a_variable.webp) In the call editor you will enter the following in place of the URI: ```http {{test_uri_1}}/rest_of_the_apicall ``` Which would look like this before saving the call: ```text GET {{test_uri_1}}/rest_of_call HTTP/1.1 Host: api.example.com Content-Length: 0 Accept: application/json User-Agent: APImetrics/<version> PycURL/<version> libcurl/<version> OpenSSL/<version> ``` Or, in the editor. ![Monitor Edit screen with the call URL using a variable in place of the root URI](https://docs.apicontext.com/img/0405589-example_with_variable.webp) When you save the call and run it, the URI will be placed into the call. ```text GET http://api.example.com/rest_of_call HTTP/1.1 Host: api.example.com Content-Length: 0 Accept: application/json User-Agent: APImetrics/<version> PycURL/<version> libcurl/<version> OpenSSL/<version> ``` The `User-Agent` line in these examples is illustrative. For its format, see [Identify and allow-list APIContext monitor traffic](https://docs.apicontext.com/concepts/identifying-monitor-traffic.md). ![Monitor Edit screen after the variable resolves, showing the final call with the substituted URI](https://docs.apicontext.com/img/3b7d126-final_call_example.webp) --- # JSON filters and tests reference > The Jinja filters and tests you can use in a monitor's assertion checks to filter lists in JSON content, with descriptions and parameters. Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/json-filters-and-tests-reference The assertion checks use a cut-down version of the Jinja templating library. To use a filter to find an item in a list and extract it as a variable, see [JSON: advanced features - filtering a list & returning a value](https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls/json-advanced-features-filters-and-tests.md). ## Filters available More information on the filters is available in the [Jinja templating library documentation](https://jinja.palletsprojects.com/en/2.10.x/templates/#list-of-builtin-filters). A selection of useful filters include: | Filter | Description | Parameters | | --- | --- | --- | | first | Returns the first item in a list | | | join | Joins a list into a string, e.g. list\|join(", ") creates a comma separated list | String to join values with\ attribute - attribute to use from list objects | | last | Returns the last item in a list | | | length | Returns the length of a list | | | map | Applies a filter on a sequence of objects or looks up an attribute. This is useful when dealing with lists of objects but you are really only interested in a certain value of it. | attribute - attribute to look up from list objects | | reject | Filters a sequence of objects by applying a test to each object, and rejecting the objects with the test succeeding. | Test for filter (see below) | | rejectattr | Filters a sequence of objects by applying a test to the specified attribute of each object, and rejecting the objects with the test succeeding. | Attribute to look up from list objects\ Test for filter (see below) | | replace | Return a copy of the value with all occurrences of a substring replaced with a new one. | | | select | Filters a sequence of objects by applying a test to each object, and only selecting the objects with the test succeeding. | Test for filter (see below) | | selectattr | Filters a sequence of objects by applying a test to the specified attribute of each object, and only selecting the objects with the test succeeding. | Attribute to look up from list objects\ Test for filter (see below) | | sort | Sort an iterable | reverse - reverse sort\ case\_sensitive - whether sorting is case sensitive\ attribute - attribute to sort by | | unique | Returns a list of unique items from the given iterable. | case\_sensitive - whether sorting is case sensitive\ attribute - attribute to sort by | ## Tests available Tests are used as part of the filters. More information on the tests is available in the [Jinja templating library documentation](https://jinja.palletsprojects.com/en/2.10.x/templates/#list-of-builtin-tests). A selection of useful tests include: | Test | Description | | --- | --- | | eq, equalto, == | Equal to | | ge, >= | Greater or equal to | | gt, > | Greater than | | le, \<= | Less than or equal to | | lt, \< | Less than | | ne, != | Not equal to | | none | Returns true if the variable is null | | undefined | Returns true if the variable does not exist | --- # Configuration > Want to update your configuration for more customized results or having trouble with certain language integrations? Follow our how-tos Source: https://docs.apicontext.com/guides/advanced-features APImetrics can be configured vastly to best suit your personal needs for your infrastructure. Sometimes, certain languages need extra configuration to best work with APImetrics and give you the best results. Below are the tutorials we have for configuring your system: * [How to Send a GraphQL Query](https://docs.apicontext.com/guides/advanced-features/graphql-queries.md) --- # Environment Variables > An overview of workflow, global, and environment variables in APImetrics, how to reference them in URIs and parameters, and available system variables. Source: https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics ## Variables: The basics You can make use of three key types of variable in APImetrics: * [Workflow variables](https://docs.apicontext.com/guides/creating-a-workflow.md) - that are extracted and used in a specific sequence of linked monitors that execute one after another * [Global variables](https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/key-concepts.md) - that are set for all users in a specific project * Environment variables - that can be set for a specific set of tests that are specified in the editor ## Using variables in a call Once you have set a variable, either by extracting a value from a response in a workflow, or in the variables setting options you can use the variable in several ways. ## In a URI For example, you have set a variable called EXAMPLE\_PATH\_SET and you want to make it part of your monitor, you can use either "\_\_" or "%%" to frame the variable name when you set the URI for a monitor. ```text https://api.example.com/__EXAMPLE_PATH_SET__ https://api.example.com/%%EXAMPLE_PATH_SET%% ``` ## As a Parameter In the monitor editor you can specify the name of the variable using the same method as for a URI. If you use a variable called TOKEN, here are the two examples for using it in the editor. ![API call config with AccessToken parameter set to __TOKEN__ and the request preview](https://docs.apicontext.com/img/3aa2d3a-token_example.webp "token example.png") ![API call config with AccessToken set to %%TOKEN%% showing the URL-encoded request preview](https://docs.apicontext.com/img/17cb23d-token_example_2.webp "token example 2.png") ## System Variables In addition to variables you can set yourself or extract from the result of another call, we also provide a set of [system variables](https://docs.apicontext.com/concepts/environment-variables/apimetrics-defined-variables.md) to handle common API logic such as setting a UNIX DATE/TIME or generating a random number or location. We even provide a means for generating a valid Credit Card number that will pass a simple checksum calculation as valid for Visa, Mastercard, and Amex. --- # Parsing Content in API calls > Guides to parsing returned header or body content for use in assertions or creating variables. Source: https://docs.apicontext.com/guides/advanced-features/parsing-content-in-api-calls Headers and Returned content can be parsed in order to validate the content for use in assertions and conditions OR to set a variable for future use. --- # Conditions and Assertions > Set conditions and assertions on the results of monitors in the Assertions section of a monitor's Edit tab, including timing-based conditions. Source: https://docs.apicontext.com/guides/blash/setting-conditions-on-calls ## Key Concepts > **Setting Assertions/Conditions in a monitor** > > The main way to handle assertions/conditions is the **Assertions** section of the monitor's **Edit** tab. Timing-based conditions are in its **Timing** part, and project-wide latency conditions are under [Project Conditions: Latency](https://client.apimetrics.io/assertions/latency) in the sidebar. APImetrics reviews results returned by a monitor in a specific sequence. Beyond status codes and timing, you can use conditions to validate [business rules](https://apicontext.com/features/business-rules) (pricing, eligibility, compliance, and routing logic) so the right team is alerted when business logic breaks. * HTTP Status Code * Response Body Size * Header Content * Body Content * Monitor Timing ![Monitor editor Conditions tab with the Project Variables panel for status code, body, and timing assertions](https://docs.apicontext.com/img/5be741e-conditions.webp) ## Default Settings By default, a call that returns a HTTP 2xx status code is considered a pass and one that returns a 5xx code is considered a fail. However, from the **Assertions** section of the monitor's **Edit** tab you can change the defaults (for instance, to consider HTTP 4xx status codes as fails or, for negative testing, HTTP 2xx status as fails) and parse results or set specific timing-based rules. > **Default pass HTTP 2xx status code** > > By default, a pass is any code returned with a 2xx result. > **Default failure HTTP 5xx status code** > > By default, any 5xx code is deemed a failure > **Default warning HTTP 4xx status code** > > Typically, a warning is due to an authentication error with the monitor and warnings are not usually handled in the statistics that focus on pass and fail. ## Result Events When a condition is met, there are 4 possible outcomes * ignore the result (no change) * treat the result as a pass, * treat the result as a failure * treat the result as a warning. Alerts can then be keyed to work off the triggered event. Different handling events and triggers can be set for a True or False result. ![Response Body assertion in the Conditions tab with the result-event dropdown set to Warning or Error](https://docs.apicontext.com/img/2077d6f-condition_results.webp) ![Conditions tab assertion row with assert and extract fields and an event handler setting the result to Warning](https://docs.apicontext.com/img/cf18284-event_handlers.webp) --- # Monitor Stats > Every API call has a set of detailed API stats that can be analyzed separately Source: https://docs.apicontext.com/guides/blash/looking-at-stats ## Key Concepts APImetrics provides a variety of views of the statistics of each test that allows you to understand at a glance the behavior of each call. As you deploy API test calls, APImetrics starts logging results. You can get to the stats for a specific test from the Quality Analytics view, a report, the home page, the list of calls or the call edit page. The statistics for an individual test can be viewed either by all cloud locations by day, month, or year, and by individual cloud location. [API Statistics view](https://www.youtube.com/watch?v=A63_3TPrV6I&t=7s) The views available are: * global latency analysis showing calls broken down by call portion and percentile * pass-fail rates - clicking on a day will take you to the filtered results for that day * latency over time * latency heatmap * latency histogram showing distribution of results * returned content size - useful for spotting content errors Clicking on any view will take you to a larger version of it. You can also save latency graphs as reports. ![Monitor Statistics overview showing Pass rate, Failure rate, Fastest and Slowest period, Latest Quality score, Latency Map, and Latency chart](https://docs.apicontext.com/img/da36b18-stats_page.webp "Monitor Statistics overview") ## Latency Map The analysis map gives you a geographical breakdown of total latency (or any specific latency component) by the locations of the data center (cloud location) the calls are being made from. You can zoom in on the map to see what is happening in a particular area more clearly. ![Latency Map with color-coded circles sized by latency across data center locations, with metric and percentile controls](https://docs.apicontext.com/img/3323a02-lataency.webp) Guide to image: 1. The larger a circle, the longer (slower) the call. Smaller circles are shorter (faster). Each circle is color-coded to the cloud it represents 2. Metric - pick the monitor latency component you are interested in seeing 3. Percentile Picker 4. Domain Picker 5. IP Address call made to 6. Switch to logarithmic circles to make it easier to compare small and large results 7. Cloud data center (location) picker 8. Region picker 9. IP Address - display results by IP address called - use in conjunction with 5) ## Pass/Fail ![Pass/Fail block calendar showing green days (all passing) and a red cell on May 17 (some failures)](https://docs.apicontext.com/img/c42b2a1-Pass_Fail.webp "Pass/Fail block calendar") The Pass/Fail views gives you a quick overview of how the call has been behaving over the last few weeks. A green box indicates that there were no failures during that day. A red and green box indicates there were some failures during that day as well as passes. A red, yellow, and green box indicates that there were some failures and warnings during that day as well as passes. ## Latency Graph ![Latency graph showing average latency over the last month, fluctuating between 200–280 ms](https://docs.apicontext.com/img/d2a5618-Latency_Graph.webp "Latency graph") The latency graph shows how latency has varied over the last few weeks. By default it shows the mean. Use the **statistic** picker to show the 90th, 95th, or 99th percentile instead. ## Latency Heatmap ![Latency heatmap showing latency by day of week, color-coded from green (fast) to red (slow)](https://docs.apicontext.com/img/13eace1-Latency_Heatmap.webp "Latency heatmap") ## Latency Histogram ![Latency histogram showing the distribution of response times, with the majority of calls completing in the 200–300 ms bucket](https://docs.apicontext.com/img/675bdcf-Latency_Histogram.webp "Latency histogram") ## Response Size ![Response Size chart plotting response size in bytes over September, trending up from about 13M to 16M](https://docs.apicontext.com/img/ed2c19a-Response_Size.webp) --- # Observability (beta) > Want to know what observability adaptor options we have for live API calls? Source: https://docs.apicontext.com/guides/integrations/observability-adaptors Below are the tutorials for all our observability adaptors: * [Akamai CDN](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-akamai-cdn.md) * [AWS CloudFront](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-aws-cloudfront.md) * [.NET](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-net.md) * [Express.js](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-expressjs.md) * [Kong Gateway](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-kong-gateway.md) * [Kubernetes](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-kubernetes.md) * [Python (WSGI)](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-python-wsgi.md) --- # Third Party Logs > How APIContext pairs outside-in synthetic monitoring with inside-out data from CDNs, WAFs, API gateways, and other internal infrastructure sources. Source: https://docs.apicontext.com/guides/integrations/third-party-logs APIContext offers the ability to add in third party information to enhance the visibility of synthetic monitoring calls. This paris our outside-in telemetry with inside-out data from a variety of sources that have visibility to internal networking data on specific call routing, including CDNs, WAFs, API gateways, and other internal infrastructure. --- # Akamai DataStream2 (DS2) Logs > How Enterprise customers create a filtered Akamai DataStream2 stream to bring CDN and WAF logs into APIContext alongside synthetic monitoring telemetry. Source: https://docs.apicontext.com/guides/integrations/third-party-logs/akamai-datastream2-ds2-logs Bring Akamai CDN/WAF logs into APIContext so you can view **external signal** (e.g., **TTFB**) alongside **internal delivery details** (edge-to-origin timing, parent hops, etc.). This integration filters your DS2 stream to only include **APIContext synthetic monitoring** calls, minimizing volume and keeping your telemetry focused. > **Who is this for?**\ > APIContext **Enterprise** customers. If you also use **Akamai TrafficPeak**, we’ll coordinate directly with the TrafficPeak team to wire everything up. ## What you’ll get **Consolidated Performance Metrics** from external and internal sources, including DNS resolution, Connect Time, Time to First Byte (TTFB), Edge to Origin, Parent Hops, and other metrics available from DS2 data sets. ## Prerequisites * **Akamai Control Center access** with permission to **create DS2 stream definitions**. * **DataStream 2** enabled on your contract. * **APIContext Enterprise plan**. * (Optional) **TrafficPeak** subscription with your Akamai team. > **Note on DS2 filtering**\ > DS2 supports including/excluding log lines using match criteria (configured via the **Log Request Details** behavior). We’ll use this to isolate APIContext synthetic calls. ## Before you start * Plan to create a **new DS2 stream** specifically for this integration (don’t modify an existing stream). * Identify the **properties** (Akamai configs) that your synthetic monitors hit. * Decide whether you’ll deliver logs to **TrafficPeak** (recommended if you already use it). ## Step 1: Let us know you're adding a DS2 integration * **[Contact support](https://apicontext.com/support).** * We will reply with confirmation of your plan, and a custom HTTPS endpoint to send the DS2 logs (if needed). ## Step 2: Create a new DS2 stream 1. Log in to **Akamai Control Center** → **COMMON SERVICES** → **DataStream** → **Create stream**. 2. Choose JSON **log format**. 3. For **destination**, select HTTPS endpoint and configure it with the custom endpoint provided by the APIContext support team. > For questions on DS2 configuration, please see DS2 documentation at: [https://techdocs.akamai.com/datastream2/docs/features](https://techdocs.akamai.com/datastream2/docs/features) ## Step 3: Select data set fields (include TTFB) In the **Data sets** step, include the following recommended fields: ![Akamai DataStream 2 data set fields grouped by category with recommended fields for APIContext checked](https://docs.apicontext.com/img/d29177fdbff18a97d2dfeb815b80315ed1789ae1fabc3ae1eefeb72421a546ed-DataStream2_Fields_for_APIContext.webp) ## Step 4: Filter to APIContext synthetic traffic Use DS2’s **include/exclude match criteria** (via the **Log Request Details** behavior) to only log synthetic calls that carry the APIContext header: * **Header to filter on:** `X-APIContext-Agent` * **Action:** *Include* log lines **only when** this header is present (or equals your expected value, if you set one). This keeps the stream **lightweight**: volume tracks your **synthetic cadence** rather than full site traffic. > **Why header (not UA)?**\ > Headers are explicit and less fragile than user-agent parsing. DS2’s match criteria let you target request headers directly. ## Step 5: Add the APIContext `traceparent` to each log line To correlate logs with synthetic journeys, add a **custom log field** that forwards the `traceparent` ID included with every APIContext synthetic request. * **Name/value format in DS2:** `apic_traceparent=VALUE` * Configure this using DS2’s **Custom log field** capability (defined in **Log Request Details**). > We’ll extract `apic_traceparent` into its own column on our end for joins and drill-downs. > > ## Step 6: Let us know! Update your support request to let us know DataStream2 is configured. If you have **TrafficPeak**, we will work with the TrafficPeak team directly to deliver our feed into your existing TrafficPeak account. If you do not have TrafficPeak, we can add your DS2 logs into APIContext, using the custom HTTPS endpoint provided earlier. ## Performance & volume notes * This integration is **lightweight**: it only logs **filtered synthetic** traffic based on your test cadence. --- # Install With Akamai CDN > If you want APImetrics to monitor API calls in your Akamai CDN, use these steps to build an Akamai EdgeWorker. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-akamai-cdn > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for Akamai CDNs allows you to monitor your live API traffic from Akamai, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are routed through Akamai, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. > **This integration is part of our Observation offering. If you are interested in using this integration, please [contact support** ## Prerequisites To be able to set up the APImetrics integration with Akamai, you will need: * Access to EdgeWorkers on your Akamai account. * The APImetrics code bundle. To request it, [contact support](https://apicontext.com/support). * Enhanced TLS enabled on the Property to which you wish to add the APImetrics EdgeWorker. ## Create an EdgeWorker ID To create an **EdgeWorker ID**, follow [Akamai’s create-an-EdgeWorker-ID instructions](https://techdocs.akamai.com/edgeworkers/docs/create-an-edgeworker-id) in the Akamai documentation. We recommend setting the resource tier to **Dynamic Compute** for the **APImetrics EdgeWorker**. ## Add EdgeWorker Behavior Once you've created an **EdgeWorker ID**, follow [Akamai’s add-an-EdgeWorker-behavior tutorial](https://techdocs.akamai.com/edgeworkers/docs/add-the-edgeworkers-behavior) in the Akamai documentation to add an **EdgeWorker Behavior**. ## Deploy APImetrics Code Bundle Create a new API Key for APImetrics by [generating an API Key](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. Next, you will be able to upload the APImetrics code bundle, by following the [code-bundle deployment steps](https://techdocs.akamai.com/edgeworkers/docs/deploy-hello-world-1). Since you are unable to edit the code bundle in the first version, you will have to create a new version and bump the version number to change the API Key to your newly generated API Key. Once you've created this new version you will be able to activate this version and monitors should now be populating your Catalog. ### Optional: Updating Your API Key If you want to update your API Key, you will need to create a new version and bump the version number like in the previous step, editing the API Key to your newly generated API Key. --- # Install with AWS CloudFront > Build or redeploy the APIContext Lambda@Edge function in your CloudFront network so APIContext can monitor the live API traffic routed through it. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-aws-cloudfront > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for AWS CloudFront networks allows you to monitor your live API traffic from AWS CloudFront, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are routed through AWS CloudFront, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. > **This integration is part of our Observation offering.** ## Prerequisites There are a few things that need to be set up or in use before integrating APImetrics into your development process. You will need the following: * An AWS account. * A CloudFront distribution that manages content delivery for the service you wish to monitor. * The ability to deploy a Lambda\@Edge function. There are two options for adding APImetrics to your CloudFront network, due to the nature of Lambda\@Edge functions, only one function is allowed. * If you **do not** currently have a Lambda\@Edge function, follow the [new-function instructions](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-aws-cloudfront.md#handler), which should take about 20 minutes. * If you **do** currently have a Lambda\@Edge function, follow the [existing-function instructions](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-aws-cloudfront.md#library-for-existing-lambdaedge-function), which should take about 3 minutes. Create a new API Key for APImetrics by following [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. > **Note: We recommend frequently rotating your API Keys for added security. To do this, simply delete your current API Key and follow the instructions for [generating an API Key** ## Architecture Below is a diagram of how this integration works: ![Architecture diagram of CloudFront Lambda@Edge function communicating with Darkspark via HTTP](https://docs.apicontext.com/img/c313148-Diagram.webp) ## Before Starting > **Note: Do not use your AWS root user privileges for these operations, as you could accidentally make an unrecoverable error.** As a best practice, always use the principle of least-privileged access when deploying new functionality into your environment, including for APImetrics. To analyze your API data, APImetrics requires access to monitor monitors. ### Library for Existing Lambda\@Edge Function If you are already using an existing **Lambda\@Edge** function, add the package as a dependency to your Lambda's source directory with the following command: ```shell npm install darkspark-aws-lambda-edge-plug ``` Once you have installed the package, you can import it into your project like so: ```javascript const { useDarkspark } = require("darkspark-aws-lambda-edge-plug"); ``` Integrate it into your handler function, by calling `useDarkspark` with the incoming event: ```javascript exports.handler = async function(event, context, callback) { await useDarkspark(event, "<your APImetrics API key>"); // other lambda logic ... ``` ### Handler ### Create a Lambda Function > **Note: When creating the Lambda\@Edge function, the region must be set as us-east-1.** Firstly, search for **Lambda** in AWS. ![AWS console search results for Lambda with the Lambda service highlighted](https://docs.apicontext.com/img/5d6bfd0-lambda1.webp) From here, create a new **Lambda function**. ![AWS Lambda console with the orange Create function button highlighted](https://docs.apicontext.com/img/d8e07cf-lambda2.webp) **Name** your Function, confirm the runtime is set as **Node.js 18.x** and ensure the Architecture is set to **arm64**. ![Lambda Basic information form with function name, Node.js 18.x runtime, and arm64 architecture selected](https://docs.apicontext.com/img/ac185d6-lambda3.webp) Next, expand the **Change default execution rule** option. ![Lambda Permissions section with the Change default execution role option highlighted](https://docs.apicontext.com/img/cc1cd81-lambda4.webp) Select **Create a new role from AWS policy templates**. ![Execution role options with Create a new role from AWS policy templates selected](https://docs.apicontext.com/img/fa35895-lambda5.webp) Select **Policy Templates**. ![Policy templates dropdown field highlighted in the Lambda execution role settings](https://docs.apicontext.com/img/3dc249c-lambda6.webp) A search bar will pop up and you can now search for **CloudFront**. There will only be one option for **Basic Lambda\@Edge permissions**. ![Policy templates search for cloudfront showing the Basic Lambda@Edge permissions option](https://docs.apicontext.com/img/f26cc61-lambda7.webp) **Name** this Role and **Create function**. ![Role name field filled in and the Create function button highlighted](https://docs.apicontext.com/img/ddb931c-lambda8.webp) ### Upload & Set Darkspark as Handler You'll automatically be taken to an overview of the new Lambda function. Select **Upload from** in the **Code source** section and choose to upload for a **.zip file**. ![Code source section with Upload from menu open and .zip file option highlighted](https://docs.apicontext.com/img/8d9e92d-lambda9.webp) The file you need to upload can be [downloaded as the Lambda@Edge package](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/darkspark_aws_lambda_edge_nodejs.zip). In the upload popup, select **Upload** and navigate to where you downloaded the zip file and then upload. ![Upload a .zip file dialog with the Upload button highlighted](https://docs.apicontext.com/img/858afe9-lambda10.webp) Once this file has been uploaded, select **Save**. ![Upload dialog showing the selected darkspark zip file with the Save button highlighted](https://docs.apicontext.com/img/c4168e8-lambda11.webp) Next, go to **Runtime settings** further down the page and select **Edit**. ![Runtime settings panel with the Edit button highlighted](https://docs.apicontext.com/img/b327e92-lamdba12.webp) From here, change the handler to `darkspark.handler` and **Save**. ![Edit runtime settings with Handler set to darkspark.handler and the Save button highlighted](https://docs.apicontext.com/img/5c5b8e3-lambda13.webp) Next, go to **Actions** at the top of the page and select **Publish new version**. ![Function page with the Actions menu open and Publish new version highlighted](https://docs.apicontext.com/img/91bc09e-lambda14.webp) You can add an optional description if you want and select **Publish**. ![Publish new version from LATEST dialog with optional description field and Publish button highlighted](https://docs.apicontext.com/img/2bba6b3-lambda15.webp) **Copy** the new function ARN, ensuring it has the version number at the end, i.e. :1 at the end. ![Function ARN ending in :1 with the copy-to-clipboard icon highlighted](https://docs.apicontext.com/img/20a343a-lambda16.webp) ### Go to CloudFront & Configure the Behaviors Search for **CloudFront** in AWS. ![AWS console search results for CloudFront with the CloudFront service highlighted](https://docs.apicontext.com/img/a4a3c32-lambda17.webp) Select whichever **Distribution** you wish to attach APImetrics to. Select **Behaviors** from the tabs. ![CloudFront distribution tabs with the Behaviors tab highlighted](https://docs.apicontext.com/img/dbe434f-lambda18.webp) Select the behavior you want to attach APImetrics to and press **Edit**. ![CloudFront Behaviors toolbar with the Edit button highlighted](https://docs.apicontext.com/img/b020409-lambda19.webp) Scroll to the bottom of the options to **Function Associations**. Go to **Origin response** and then select **Lambda\@Edge** from the dropdown and paste the copied function **ARN**. Finally, **Save changes**. ![Function associations with Origin response set to Lambda@Edge, the ARN pasted, and Save changes highlighted](https://docs.apicontext.com/img/f380e52-lambda20.webp) ### Create API Key You will need to create a new APImetrics API Key, see [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key). Copy the key for use later. ### Add APImetrics as a Header Return to **CloudFront** then select **Origins**. ![CloudFront distribution tabs with the Origins tab highlighted](https://docs.apicontext.com/img/ded5650-lambda21.webp) Select the **Origin** you have chosen to attach APImetrics to and press **Edit**. ![CloudFront Origins toolbar with the Edit button highlighted](https://docs.apicontext.com/img/14051b4-lambda22.webp) Scroll to **Add custom header** and select the **Add header** button. ![Add custom header section with the Add header button highlighted](https://docs.apicontext.com/img/b4eb18f-lambda23.webp) Paste `x-darkspark-api-key` in the **Header name** field and your newly generated API Key in the **Value** field. Then, **Save changes**. ![Custom header with X-DARKSPARK-API-KEY name and API key value entered, Save changes highlighted](https://docs.apicontext.com/img/924a7b2-lambda24.webp) This is the process complete. It will take a couple of minutes to deploy fully. ## Maintenance > **With some updates to Darkspark, we may need to release a new version of the CloudFront plug. In this case, you will need to download the newest version of the plug and redeploy using the steps on this page.** Want to know when we make these newest versions? Check the [Changelog](https://docs.apicontext.com/changelog.md). ## FAQ ### There is an issue with the downloaded package. What do I do? *** First, try to download the package again, as there might be a newer version that you missed. If this doesn't work, please [contact support](https://apicontext.com/support). ### Can I run the handler using another language? *** Not at this time. We currently only support Node.js. If you are interested in another language, please [contact support](https://apicontext.com/support). --- # Org-level Integrations > Connect a third-party provider (such as Datadog) once at the Organization level and reuse it across projects. See how that differs from per-project webhooks. Source: https://docs.apicontext.com/guides/integrations/org-level-integrations An **Organization-level integration** is a connection to a third-party provider (for example, Datadog) that is configured **once on the Organization** and managed by Organization administrators. This is distinct from a **per-project webhook**, which is configured inside a single project and only sends data for that project's Monitors. Use an org-level integration when you want a single, centrally managed connection to an external system that applies across the Organization. Use a per-project webhook when you want alerting that is scoped to, and owned within, one project. > **Note** > > Org-level integrations are managed from the **Organization settings** area. Organization settings (including Integrations, Certificates, and Downtimes) are an Enterprise-tier capability. See the [pricing page](https://apicontext.com/pricing) for plan availability. ## Org-level integrations vs per-project webhooks The two mechanisms solve different problems. The table below summarizes where each is configured, who manages it, and what it covers. | | Org-level integration | Per-project webhook | |---|---|---| | **Where configured** | Organization settings → **Integrations** tab | Inside a project, on the **Alerts & Webhooks** page | | **Scope** | The Organization (a shared, centrally managed provider connection) | A single project's Monitors | | **Who manages it** | Organization administrators | Project Owners and Editors | | **Typical use** | One managed connection to a provider (e.g. Datadog) for the whole Organization | Route a specific project's PASS / SLOW / WARNING / FAIL events to Slack, Teams, PagerDuty, email, OpenTelemetry, etc. | | **Lifecycle** | Created, edited, and removed at the Organization level | Created, edited, and removed within the project | In short: **org-level integrations belong to the Organization and its administrators; per-project webhooks belong to each project.** For the full list of webhook providers and how to add a per-project webhook, see [Using Webhooks](https://docs.apicontext.com/guides/alerting/using-webhooks.md). ## View and manage Organization integrations 1. Open the **Organization settings** for your Organization (the gear/settings control next to the Organization picker). 2. Select the **Integrations** tab. 3. The Integrations list shows each connected provider with its **Name**, **Provider** (for example, Datadog), **Created At**, and **Last Modified**. From this tab, Organization administrators add, edit, and remove provider connections that are shared across the Organization. > **Note** > > If you do not see the Integrations tab, confirm that your account has Organization administrator access and that your plan includes Organization settings (see [plan availability and pricing](https://apicontext.com/pricing)). ## How an integration relates to other Organization settings The **Integrations** tab sits alongside the other Organization-level settings: - **Certificates**: Organization-managed mTLS and signing certificates. - **Downtimes**: Organization-wide downtime windows that all schedules respect. See [Downtimes](https://docs.apicontext.com/guides/projects/downtimes.md). These are all configured once at the Organization level rather than per project. ## See also - [Using Webhooks](https://docs.apicontext.com/guides/alerting/using-webhooks.md): per-project alerting and the full list of supported webhook providers. - [Downtimes](https://docs.apicontext.com/guides/projects/downtimes.md): Organization-wide and schedule downtime windows. - [Pricing](https://apicontext.com/pricing): plan availability for Organization settings. --- # Install with .NET > If you want APImetrics to monitor API calls to a .NET server, use these steps to build the APImetrics into your application. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-net > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for .NET applications allows you to monitor your live API traffic from .NET, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are coming from .NET, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. We have two different versions of our .NET adaptor, one for versions of [.NET 6 onwards](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-net.md#net-6-onwards) and one for versions of [.NET 4.7.2](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-net.md#net-472). ## .NET 6 Onwards ## Include the Adaptor in Your .Net Application Source Download the .NET 6 adaptor, [Darkspark.Dotnet.Core.Plug.1.0.0.nupkg](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/Darkspark.Dotnet.Core.Plug.1.0.0.nupkg), and unzip the package into your project directory. To integrate with APImetrics, you will need to create a new API Key by following [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. ## Set the Configuration Values Configuration values can be set in standard .NET configuration locations. See [Microsoft documentation](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration\&view=aspnetcore-7.0#commandline-configuration-provider) for full documentation and precedence order. Required: * **API\_KEY** - The APImetrics API Key for this application. Optional: * **NODE\_LOCATION** - The location of the node executable on the system. * Default set to "node". * **SCRIPT\_LOCATION** - As part of the build process, the relevant script file is placed in a APImetrics folder relative to the bin files. If you wish to locate the script file elsewhere, it can be specified here. * Default set to `./Darkspark/darkspark_core.js`. Example configuration for appsettings.json: ```json { "Darkspark": { "API_KEY": "key-abcdef", "NODE_LOCATION": "c:\\temp\\node.exe", "SCRIPT_LOCATION": "./ExternalScripts/ds.js" } } ``` Example configuration for the environment variables: > **Note: The required Darkspark\_\_ prefix** ```javascript export Darkspark__API_KEY=key-abc export Darkspark__NODE_LOCATION=mySpecialNode export Darkspark__SCRIPT_LOCATION=../scripts/here.js ``` ## Enable Request Buffering To allow the APImetrics .NET 6 adaptor to work, it is necessary to **enable request buffering** so that the body can be read more than once. This is done by adding the following to the configure method of the **startup.cs (or equivalent)**. Note in this context, the app is an IApplicationBuilder. ```csharp app.Use(async (context, next) => { context.Request.EnableBuffering(); await next(); }); ``` ## Decorate the Controllers/Methods to Enable Observations To enable observation, it is simply a case of adding the **[Darkspark]** attribute at either the controller level or at an individual method. ### Optional: Set the Logging Level Logging can be set on the Darkspark namespace if a level other than the application default is required. For example, to enable DEBUG level logging, use the following: ```csharp "Logging": { "LogLevel": { "Default": "Information", "Microsoft": "Warning", "Darkspark": "Debug" } } ``` ## .NET 4.7.2 > **Note: This plug only builds on Windows.** This adaptor runs on .NET Framework 4.7.2. Special CI pipelines `dotnet4-check` and `dotnet4-publish` test and build this component on GitHub Actions Windows runners. The project can also be built correctly in Visual Studio 16 or 17. The .NET adaptor uses nodejs. You can [download Node.js](https://nodejs.org/). ## Using the Adaptor in a .NET Framework Project A valid APImetrics API key is required to start observing in a .NET Framework project, follow [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choose **Ingress** as your **Access Level**. Download the .NET 4.7.2 adaptor, [Darkspark.Dotnet.Plug.1.0.0.nupkg](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/Darkspark.Dotnet.Plug.1.0.0.nupkg). Once the NuGet package is installed in the project, to enable APImetrics, a few additional lines are required in the `WebApiConfig.cs` file. * A call to **Darkspark.Dotnet.Plug.Helpers.SetupHelper.Register** takes the API key and an optional Logging.LogLevel (defaults to Information). * A call to **config.MessageHandles.Add** registers the Darkspark observer to look at any calls made on any ApiController in the application. Here's an example using an API key "key-valid" and setting the logging level to Debug: ```csharp // Darkspark setup Darkspark.Dotnet.Plug.Helpers.SetupHelper.Register("key-valid", Microsoft.Extensions.Logging.LogLevel.Debug); config.MessageHandlers.Add(new Darkspark.Dotnet.Plug.Delegates.ObserveDelegate()); ``` --- # Install with Express.js > If you want APImetrics to monitor API calls to a Node express.js server, use these steps to build the APImetrics adaptor into your application. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-expressjs > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for Express.js applications allows you to monitor your live API traffic from Express.js, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are coming from Express.js, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. ## Download the Express.js Adaptor To download the Express APImetrics adaptor, use the following: ```shell npm i darkspark-expressjs-plug ``` To download to a specific directory, follow [the npm install guide](https://docs.npmjs.com/cli/v6/commands/npm-install). Otherwise, this will automatically download to the `node-modules` folder in your root directory. ## Include the APImetrics Adaptor in Your Express.js Application Source In the source file in which your express instance is created, `require` the downloaded adaptor: ```javascript const { darkspark, darksparkVerify } = require("darkspark-expressjs-plug"); ``` The `darkspark` function should be called with your Express application as its first argument, and your APImetrics API key as its second argument. To create a new API Key for APImetrics by following [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. For example: ```javascript const app = express(); darkspark(app, "key_abcdef"); ``` The `darksparkVerify` function should be included in the `verify` option on any body-parser middleware you have installed on your application. Depending on your setup, this may look like any of the following: ```javascript bodyParser.json({ verify: darksparkVerify, }); ``` ```javascript bodyParser.urlencoded({ verify: darksparkVerify, }); ``` ```javascript app.use(express.json({ verify: darksparkVerify, })); ``` ```javascript app.use(express.urlencoded({ extended: true, verify: darksparkVerify, })); ``` This completes the setup. The next time you deploy your application, incoming monitors will be captured by the Catalog. --- # Install with Kong Gateway > If you want APImetrics to monitor APIs traversing a Kong Gateway, use these steps to install APImetrics into the environment where you run Kong. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-kong-gateway > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for Kong Gateway allows you to monitor your live API traffic from Kong, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are routed through Kong, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. This can be done either locally via Docker or in a hosted environment. > **Note: The JavaScript plugin server requires the use of Kong 2.3 or higher.** ## Enable the Kong JavaScript Plugin Server The APImetrics adaptor is written in JavaScript, so Kong’s JS plugin server must be running. If you don't already have the plugin server, [kong-js-pdk](https://github.com/Kong/kong-js-pdk) can be installed using `npm`. To install the plugin server binary globally: ```shell npm install kong-pdk -g ``` Set the JS plugin server using the following environment variables: ```php # If KONG_PLUGINSERVER_NAMES already has additional values, just add js to the list ENV KONG_PLUGINSERVER_NAMES js ENV KONG_PLUGINSERVER_JS_SOCKET /usr/local/kong/js_pluginserver.sock ENV KONG_PLUGINSERVER_JS_START_CMD "/usr/local/bin/kong-js-pluginserver -v --plugins-directory /usr/local/kong/js-plugins" ENV KONG_PLUGINSERVER_JS_QUERY_CMD "/usr/local/bin/kong-js-pluginserver --plugins-directory /usr/local/kong/js-plugins --dump-all-plugins" ``` > **Note: Throughout this document, we assume JavaScript plugins are stored in: /usr/local/kong/js-plugins. If your deployment has been customized, update the environment variables accordingly.** For more details on configuring Kong's JS plugin server, see [Kong’s JavaScript plugin server documentation](https://docs.konghq.com/gateway/latest/plugin-development/pluginserver/javascript/). ## Add the APImetrics Adaptor to the Kong Plugin Directory Download the APImetrics adaptor, [darkspark\_kong.js](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/darkspark-kong-plug-1.3.0.tgz). Add `darkspark_kong.js` to the directory `/usr/local/kong/js-plugins`. Add the APImetrics adaptor as an environment variable. Find the `KONG_PLUGINS` environment variable (depending on how your deployment is set up, this may be part of a docker configuration, like the example shown below, or set by a deployment/startup script) and append `darkspark` to the existing list. ```php # Allow plugins to be used. The plugin name is not the JS file name e.g. darkspark_kong.js ENV KONG_PLUGINS "bundled,darkspark" ``` > **Note: Do not remove “bundled,” as the bundled plugins are required by Kong.** If you are unsure whether the environment variable is currently set, simply run the following command: ```shell export | grep KONG_PLUGINS ``` A typical output from this command would be: ``` export KONG_PLUGINS='bundled,contxt' export KONG_PLUGINSERVER_JS_QUERY_CMD='/usr/local/bin/kong-js-pluginserver --plugins-directory /usr/local/kong/js-plugins --dump-all-plugins' export KONG_PLUGINSERVER_JS_SOCKET='/usr/local/kong/js_pluginserver.sock' export KONG_PLUGINSERVER_JS_START_CMD='/usr/local/bin/kong-js-pluginserver -v --plugins-directory /usr/local/kong/js-plugins' export KONG_PLUGINSERVER_NAMES='js' ``` If the environment variable `KONG_PLUGINS` does not currently exist, ensure it is added based on the current preferred means of managing environment variables in your infrastructure. ## Specify the APImetrics Adaptor as a Service in the Kong YML Configuration File The Kong configuration file has a services section where URLs/routes are defined - an adaptor entry should be added to any services that require APImetrics capabilities to be enabled. The Kong configuration file is located by default at `/etc/kong/kong.conf`. Open the configuration file, and add a new entry to each service, after the name and URL. The entry required is: ```javascript - name: darkspark config: api_key: `<API-KEY>` ``` Replace `` with your APImetrics API key. To create a new API Key for APImetrics by following [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. An example of the configuration file with APImetrics entries added is below: ```javascript services: - name: londonstockexchange-service url: https://www.londonstockexchange.com plugins: - name: darkspark config: api_key: `<API-KEY>` routes: - name: londonstockexchange-host-route hosts: - www.londonstockexchange.com - name: local-pii url: http://host.docker.internal:9090 plugins: - name: darkspark config: api_key: `<API-KEY>` routes: - name: local-pii-route paths: - / ``` Now your APImetrics adaptor is configured. Navigate to the Catalog to see data populating. ## Install APImetrics Adaptor With Kong Gateway Locally on Docker ## Download the Docker Package Download [the Kong Gateway Docker image](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/kong-gateway-docker-image.tar.gz). To use this: 1. Decompress the tarball by using the command: `gunzip kong-gateway.tar.gz`. 2. Import the image into Docker by using the command: `docker load -i kong-gateway.tar.gz`. 3. Run the image in Docker, supplying a Kong configuration file by using the command: `docker run -v '/path/to/kong-config.yml:/etc/kong/declarative.yml:ro' kong-gateway`. Update the sample Kong configuration file with your variables, and include the APImetrics adaptor in the plugins section for the required services. For more details, see Specify the [Darkspark Plugin as a Service in the Kong YML Configuration File](https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-kong-gateway.md#specify-the-apimetrics-adaptor-as-a-service-in-the-kong-yml-configuration-file). > **Note: If you are targeting services running locally, use host.docker.internal instead of localhost.** Now, the Kong Gateway is running, you can make calls to it at `http://localhost:8000`. The calls you make will populate the Catalog. --- # Install with Kubernetes > If you want APImetrics to monitor API calls as a Kubernetes sidecar, use these steps to add the APImetrics adaptor into your application. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-kubernetes Our Observability Adapter for Kubernetes applications allows you to monitor your live API traffic from Kubernetes, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are coming from Kubernetes, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. # Add the APImetrics Adaptor to the YAML File Open your existing deployment Kubernetes YAML file for your application. Find the section where you define the containers for your pods. > **Tip: You will need to create a new API Key for APImetrics by following [the API Key tutorial** Add the following snippet of code inside the **containers section**: ```javascript - name: darkspark-sidecar image: bycontxt/darkspark-sidecar imagePullPolicy: IfNotPresent resources: limits: cpu: 1000m memory: 256Mi requests: cpu: 1000m memory: 256Mi env: - name: DARKSPARK_API_KEY value: <API KEY HERE> ``` Replace <API KEY HERE> with your newly generated API key. Remember best practices for security - your API Key should be sourced from your secrets or configmaps and not pasted directly into your YAML file. Now, when you run your Kubernetes application, your monitors will populate the Catalog. --- # Install with Python (WSGI) > If you want APImetrics to monitor API calls to a Python web server, use these steps to build the APImetrics adaptor into your application. Source: https://docs.apicontext.com/guides/integrations/observability-adaptors/install-with-python-wsgi > **This adaptor is currently in beta. For questions, [contact support** Our Observability Adapter for Python (WSGI) applications allows you to monitor your live API traffic from Python, without configuring monitors manually in the APImetrics platform. By deploying this adapter, APImetrics can read monitors that are coming from Python, and automatically build your API [Catalog](https://docs.apicontext.com/guides/catalog.md). Once integrated, you can compare your live API traffic against your OAS spec, and set up synthetic endpoint monitoring automatically. > **Note: WSGI is compatible with most of the popular Python web frameworks, including Flask, Bottle, and web2py.** # Include the APImetrics Adaptor in Your Python Application Source Ensure that [nodejs v16](https://nodejs.org/) is installed on your system and available on the executable PATH. The current APImetrics adaptor does most of its work in a separate nodejs process. Download the APImetrics adaptor, [darkspark\_python\_wsgi-0.1.0.tar.gz](https://contxt-eu-west-1-prod-plugs.s3.eu-west-1.amazonaws.com/darkspark_python_wsgi-0.1.0.tar.gz), and unzip it into your Python project directory. Add the APImetrics adaptor to your WSGI application, providing an API Key from APImetrics. To create a new API Key for APImetrics by following [the API Key tutorial](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-api-key) and choosing **Ingress** as your **Access Level**. For example, if you are using Flask, it would look like the following: ```python from flask import Flask from darkspark_python_wsgi import darkspark app = Flask("example") app.wsgi_app = darkspark(app.wsgi_app, "DARKSPARK-API-KEY") ``` This completes the setup. The next time you deploy your application, incoming monitors will be captured by the Catalog. --- # Create a new project > Create a personal project or a project in your organization, from the web UI or the CLI. Where you create it decides who owns it. Source: https://docs.apicontext.com/guides/projects/create-a-new-project You can create a project in the web UI or with the [CLI](https://docs.apicontext.com/cli.md). Every new project is one of two kinds, and where you create it decides which: | Kind | Owned by | Who can create one | |---|---|---| | **Personal project** | You. It starts as a 30-day trial project and is not part of any organization. | Anyone | | **Organization project** | The organization. Members get access through their organization role. | Organization admins | > **Projects are not added to your organization automatically** > > Being a member of an organization does not put new projects in it. To create an organization project, start from the organization (Organization Settings or the organization's panel on the Collections page) or use `create-project-in-org` in the CLI. Anywhere else, you get a personal project. ## Create a project from the web UI ### Personal project On the Collections page, use the **Add Project** button over the Quick start box, or the **Add Project** button in the Create projects box. Enter a name and select **Add**. ![Collections page projects list with the Add Project link highlighted to create a new project](https://docs.apicontext.com/img/08cfba8-Screenshot_2023-07-31_125022.webp) There is also an **Add Project** button on the Projects page. ![APIContext Settings page with the Add Project link below the Projects heading](https://docs.apicontext.com/img/5fcbd75-Screenshot_2023-07-31_125544.webp) ### Organization project You need the organization admin role. 1. Open Organization Settings: select the Settings (gear) icon above the organization name in the top bar. ![OrganizationSettings](https://docs.apicontext.com/img/0de6ffb653847b96189ac8f6712bcc6e72164198d9cec39132394054fa488680-OrganizationSettings_Icon.webp) 2. Select **+Create Project**, enter a name, and confirm. You can also create an organization project from the organization's panel on the Collections page. ## Create a project with the CLI Projects are created with [generated commands](https://docs.apicontext.com/cli/generated-commands.md). Both take a project `name`. ### Personal project ```bash apimetrics create-account-project name: "My New Project" ``` ### Organization project You need the organization admin role, and the organization's ID. 1. Find the organization ID. `list-account-projects` returns the organizations you belong to; filter the output to their IDs and names: ```bash apimetrics list-account-projects -f 'body.organizations.*.{id, name}' ``` ```json [ { "id": "example-org", "name": "Example Org" } ] ``` To check that you are an admin of that organization, list your roles per organization and look for `ADMIN`: ```bash apimetrics list-account-projects -f 'body.meta.roles' ``` 2. Create the project in that organization: ```bash apimetrics create-project-in-org <org-id> name: "My New Project" ``` Run `apimetrics create-project-in-org --help` for the optional fields (`tags`, `email`, `security_profile`). ### Select the new project [Select it](https://docs.apicontext.com/cli/reference/project.md) to make it the active project for later commands: ```bash apimetrics project select ``` --- # Getting Started - Projects and APIs > Get started after signing in to APImetrics by navigating the Collections page, creating projects, and adding APIs Source: https://docs.apicontext.com/guides/projects/getting-started-projects-and-apis ## The Collections Page If you're an enterprise user you may see your organization's collections first, otherwise you'll see your collections and be able to add any of the collections from our API directory to your account. ![Collections page showing personal projects, headline performance metrics, and API directory collections](https://docs.apicontext.com/img/aff66c0-collections_page.webp) ## Next steps... create a project, then add some APIs APIs are stored in projects, your account holds a collection of your projects. A billing subscription works for a project! --- # Invite a user to join a project > How to invite users to an APImetrics project from Project Settings and an overview of the Owner, Editor, Manager, Analyst, and Viewer access levels. Source: https://docs.apicontext.com/guides/projects/invite-a-user-to-join-a-project To invite a user to your personal project, navigate to **Project Overview** from the left-hand menu, then select the "Settings" tab to open the Project Settings page. On the Project Settings page, navigate to **Invite Users** and click on "Create Invite". In the dialog that appears, enter the user’s email address, choose the required Access Level, and click **Invite** to send the invitation. ![PersonalProjects_CreateUserInvite](https://docs.apicontext.com/img/41c5b026ebc4ec47bc8469ef2149d8c1481eb74dbc7be31c3de608dd70eb74e6-APIm_PersonalProjects_CreateInvite.webp) APImetrics supports four Access Levels, each with different levels of permissions: * **Owner** – Owns the project and has all Editor permissions, along with full project ownership capabilities. * **Editor** – Can create, edit, and delete tests, as well as manage other APImetrics resources associated with the project. * **Manager** - Can view tests and results, perform analytics tasks, and manage organization-wide downtimes and globally snooze alerts. * **Analyst** – Can view tests and results and perform selected analytics tasks. * **Viewer** – Can view tests and test results. The invited user will receive an email shortly (please check spam or junk folders if it does not arrive promptly). They can then log in to their existing APImetrics account or create a new one to join the project. To remove someone's access when they leave your team, see [Stop APIContext emails when someone leaves your team](https://docs.apicontext.com/guides/projects/remove-a-team-member.md). --- # Organizations > An organization can be a business or entity that owns a group of different collections. Users can be members of different organizations. Source: https://docs.apicontext.com/guides/projects/organizations > **Organization management features are for Enterprise customers only** For Enterprise customers, projects, and users are grouped into an organization for billing and other administrative purposes. Users with the appropriate permissions can use various functionality to manage the organization and its associated projects and users. Click on the Settings button next to the Organization box in the sidebar or select the Organization Settings item from the dropdown under the organization name in the top bar to access the Organization Settings. ![Top bar showing the Organization name dropdown and Settings gear used to open Organization Settings](https://docs.apicontext.com/img/4fa73f4-Org_Access.webp) ## Organization Settings The first section is [Organization Settings](#organization-settings) and contains information about the organization, such as the name, tags, ID, current subscription tier, request quota, amount of requests used, predicted quota usage, and your current role in the organization. From here you can also edit the name and tags for your organization. Below this information, you can toggle on and off multi-factor authentication or allow for password expiry after 90 days. Finally, you can open the [Organization Audit Logs](#audit-logs) view. ![Organization Settings page with name, subscription tier, request quota usage chart, and security toggles](https://docs.apicontext.com/img/a144ec2-Org_Settings.webp) ## Audit Logs From here, you will be able to see who created, modified, or deleted anything related to the Organization. This can include modifications to Projects or created invitations to the Organization. These logs are organized by the newest first. If you want any additional information about the log, you can click on the Diff option at the side to see what changes were specifically made and the History option to see what other changes have been made to the logged Resource. ![Organization Audit Logs listing time-stamped create, modify, and delete actions with Diff and History options](https://docs.apicontext.com/img/7285f0b-Audit_Logs.webp) ## Projects The [Projects](#projects) section lists all the projects in the organization, who has access to them and at what level. There is also additional information that can be hidden or added to this view to personalize the view to what you most need, including viewing the owners of the Projects or the percentage of the total Organization quota this project is set to use for the month. > **Users in blue are ones who are external to your organization. Users in gray are members of your organization.** ![Projects section of Organization Settings listing each project with its Editors, Analysts, and Viewers and quota usage](https://docs.apicontext.com/img/f7e03af-Projects.webp) Projects created by organization members, whether from the web UI or the [CLI](https://docs.apicontext.com/cli.md), are automatically added to the organization. See [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md) for details. From here, you can also add Editors or Analysts to different projects by selecting the Add button and choosing a role or user from the dropdown. > **If a project has no roles or accounts assigned, it can be removed from your organization permanently by clicking on the Delete button.** Access to projects can also be managed by project owners from the [Project Administration](https://docs.apicontext.com/guides/projects.md). ## Roles The [Roles](#roles) section allows you to create roles and view the roles that already exist within the Organization. ![Roles section listing organization roles such as ADMIN, DEFAULT, and EDIT with their descriptions](https://docs.apicontext.com/img/26d6e43-Roles.webp) Organizations have two default roles: DEFAULT and ADMIN. The only difference is accounts with the ADMIN role can access the Organization page. Roles can be useful as instead of giving access to a project account by account, you can provide access to a role and all accounts with that role will have access to that project. ### Add Role You can create other roles using the [Add Role](#add-role) link. ![Roles section with the Add Role link highlighted above the list of existing roles](https://docs.apicontext.com/img/4fc8d1a-Add_Role_Link.webp) A Name and Description field will appear, fill in these fields and select the Add button at the end and there will be a new role within the Organization. ![Add Role form with Name and Description fields and an Add button to create a new role](https://docs.apicontext.com/img/a2247e8-Add_Role_Form.webp) ## Accounts The second to last section is [Accounts](#accounts). In this section, you can see which accounts are members of the organization and add or delete roles for the users as required. There is also additional information that can be hidden or added to this view to personalize the view to what you most need, including viewing the account ID and whether the email address has been verified. Finally, you can also send password reset emails to account when needed and remove accounts from the Organization. ![Accounts section listing organization members with identity provider, email, roles, and last login](https://docs.apicontext.com/img/366bff1-Accounts.webp) ## Service Accounts The **Service Accounts** section is available under **Accounts** for Organization Admins. Service accounts allow Organization Admins to create non-user accounts that can authenticate with APImetrics APIs using OAuth client credentials. To create a service account, see [Create a service account](https://docs.apicontext.com/guides/projects/create-a-service-account.md). ## Invites The final section is [Invites](#invites). You can view who has been invited to the Organization, by who, and when, and delete the invitation if required. By selecting the Create Invite link, you can also invite more people to join the Organization. ![Invites section with an email and access role field for inviting people to the organization](https://docs.apicontext.com/img/f5be3c1-Invites.webp) Then you will be able to enter the email address and assign a role from the dropdown. By default, the DEFAULT role is assigned. ![Create invite form with an email address field and an access role dropdown defaulting to DEFAULT](https://docs.apicontext.com/img/40d433a-Create_Invite_Form.webp) --- # Stop APIContext emails when someone leaves your team > Remove a person's project access in Users and Admins, then take their address out of every email alert, because alert emails go to typed addresses. Source: https://docs.apicontext.com/guides/projects/remove-a-team-member When someone leaves your team, remove their access to each project, then check your email alerts. Removing a person's access does not change the alerts: an email alert sends to the address typed into it, whoever that address belongs to. ## Prerequisites - Owner or Manager access to each project the person could access. ## Steps 1. Select the project in the Project picker. 2. In the sidebar, under **Project Administration**, select **Users and Admins** ([open it in the platform](https://client.apimetrics.io/home/settings)). 3. Under **Project Administrator Settings**, find the person's email address in the list for their access level (**Owners**, **Editors**, **Analysts**, **Viewers**, or **Managers**). Select the trash icon next to it, then confirm. 4. In the sidebar, under **Configure Monitoring**, select **Alerts & Webhooks**. For each alert of type **Email**, **Email (plain text)**, or **Email (template)** that sends to the person's address, expand the alert, then either change the address in **Email** and select **Save**, or select **Delete**. 5. Check the alerts set on individual monitors too: open each monitor's **Alerts & Webhooks** tab and repeat step 4. 6. Repeat these steps for every other project the person could access. > **Tip** > > Send email alerts to a team distribution list instead of to a person. When someone joins or leaves, you change the list's members, not your alerts. ## Next steps - [Email alerts](https://docs.apicontext.com/guides/alerting/using-webhooks/email-alerts.md): the three email alert types. - [Invite a user to join a project](https://docs.apicontext.com/guides/projects/invite-a-user-to-join-a-project.md): give a new team member access. - [Manage the emails APIContext sends you](https://docs.apicontext.com/guides/projects/manage-email-settings.md): each person's own email settings. --- # Copy or move a monitor > Copy a monitor into another project or duplicate it in the same one, or move it, and see what carries over, such as its authentication setting. Source: https://docs.apicontext.com/guides/projects/copy-or-move-a-monitor Copy a monitor to reuse its setup in another project, or to make a second version of it in the same project. Move it when it belongs in a different project. ## Prerequisites - At least Editor access to the monitor's project, and Owner or Editor access to the destination project. - To move a monitor, take it off its schedules first (see [What carries over](#what-carries-over)). ## Steps 1. Open the monitor and select **Copy** or **Move** in the action bar under the page title. The button is on every tab of the monitor (**Summary**, **Edit**, **Stats**, and the rest). ![Monitor Edit page action bar with Create Report, Copy, and Move, with Copy and Move highlighted](https://docs.apicontext.com/img/monitor-copy-move-buttons.webp) Manage Resources opens with **Monitor** and this monitor already selected. You can also open it from the sidebar under **Project Administration** > **Project Export / Import** ([open it in the platform](https://client.apimetrics.io/manage)) and choose **Monitor**. To copy several monitors at once, add them in **Select the Monitor(s)**. 2. Check that **Copy** or **Move** is selected under **Copy or Move**. 3. In **Choose which project to copy this into** (or **move this into**), pick the destination. To duplicate the monitor in its own project, pick that project. 4. Read the dry run that appears. ![Manage Resources with a monitor selected, Copy chosen, a destination project picked, and the dry run saying the monitor will be copied](https://docs.apicontext.com/img/manage-resources-copy-monitor.webp) 5. Select **Copy** or **Move**, then confirm. ## What carries over **When you copy a monitor to another project:** - Its authentication setting is copied too, without its tokens. Get a new token in the destination project before the copy can run. See [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md). - A file the monitor uploads is not copied. The dry run names it. - It is not added to a schedule. Frequency and locations belong to the [schedule](https://docs.apicontext.com/concepts/schedules.md), not the monitor, so add the copy to a schedule in the destination project ([Schedule monitors](https://docs.apicontext.com/guides/schedule-monitors.md)). **When you move a monitor:** - A monitor that is on a schedule cannot be moved. The dry run names the schedule; remove the monitor from it first, then add it to a schedule in the destination project. - A monitor that uses a file cannot be moved. - Its authentication setting moves with it. If another monitor that is not moving uses the same setting, the move is blocked. - If the monitor is a step in a workflow that is not moving, it is removed from that workflow. The dry run lists each workflow it will leave. > **Give another monitor the same frequency and locations** > > You do not need to copy a monitor for this. Add the other monitor to the same schedule. ## Next steps - [Copy or move resources between projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md): the other resource types. - [Copy or move a workflow](https://docs.apicontext.com/guides/projects/copy-or-move-a-workflow.md): move a set of monitors together. --- # Copy or move a report > Copy or move a report into another project from its Copy and Move buttons or from Manage Resources. The monitors it reports on stay where they are. Source: https://docs.apicontext.com/guides/projects/copy-or-move-a-report Copy a report to reuse its layout in another project, or move it to another project. The report's monitors do not go with it. ## Prerequisites - At least Editor access to the report's project, and Owner or Editor access to the destination project. ## Steps 1. In the sidebar, under **Investigate**, select **Status Reports** and open the report. Select **Copy** or **Move** in its toolbar, next to **CSV** and **Print**. Manage Resources opens with **Report** and this report already selected. You can also open it from the sidebar under **Project Administration** > **Project Export / Import** ([open it in the platform](https://client.apimetrics.io/manage)) and choose **Report**. 2. Check that **Copy** or **Move** is selected under **Copy or Move**. 3. Choose the destination project. To duplicate the report in its own project, pick that project. 4. Select **Copy** or **Move**. A report has no dry run: nothing appears under the destination before you select the button. 5. In **Are you sure?**, select **Copy** or **Move** again. For a move, the dialog notes that the report's monitors stay where they are. ## What carries over Copying or moving a report copies or moves the report only. No monitors are copied or moved. A report in another project still reports on the monitors in the original project, so anyone viewing it needs access to those monitors. To report on monitors in the destination project, [create a report](https://docs.apicontext.com/guides/analytics/creating-reports.md) there instead. ## Next steps - [Create reports](https://docs.apicontext.com/guides/analytics/creating-reports.md): what a report shows and how to edit it. - [Copy or move resources between projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md): the other resource types. --- # Copy or move a workflow > Copy a workflow and its monitors into another project or duplicate it in the same project, or move it with its monitors once it is off its schedules. Source: https://docs.apicontext.com/guides/projects/copy-or-move-a-workflow Copy a workflow to run the same sequence of steps in another project, or to make a second version of it in the same project. Move it when the workflow and its steps belong in another project. ## Prerequisites - At least Editor access to the workflow's project, and Owner or Editor access to the destination project. - To move a workflow, take it off its schedules first. ## Steps 1. Open the workflow and select **Copy** or **Move** in the action bar under the page title. ![Workflow Edit page action bar with Create Report, Copy, and Move, with Copy and Move highlighted](https://docs.apicontext.com/img/workflow-copy-move-buttons.webp) Manage Resources opens with **Workflow** and this workflow already selected. You can also open it from the sidebar under **Project Administration** > **Project Export / Import** ([open it in the platform](https://client.apimetrics.io/manage)) and choose **Workflow**. 2. Check that **Copy** or **Move** is selected under **Copy or Move**. 3. Choose the destination project. To duplicate the workflow in its own project, pick that project. 4. Read the dry run that appears, then select **Copy** or **Move** and confirm. ## What carries over **Copy** copies the workflow and every monitor in it, whether the destination is another project or the same one. The dry run lists each monitor it will copy. In another project, the monitors' authentication settings are copied too, without their tokens, as when you [copy a monitor](https://docs.apicontext.com/guides/projects/copy-or-move-a-monitor.md#what-carries-over). The copy is not on a schedule. **Move** moves the workflow and every monitor in it, along with their authentication settings. A workflow on a schedule cannot be moved: the dry run names the schedule in red and the **Move** button stays disabled. The same applies if any of its monitors is on a schedule of its own. ![Manage Resources dry run for moving a workflow, blocked because it is scheduled by Default Schedule, with the monitors that would move listed below](https://docs.apicontext.com/img/manage-resources-move-workflow-blocked.webp) To move it, remove the workflow from its schedules, move it, and then add it to a schedule in the destination project. See [Schedule monitors](https://docs.apicontext.com/guides/schedule-monitors.md). ## Next steps - [Workflows](https://docs.apicontext.com/guides/creating-a-workflow.md): build and edit the steps of a workflow. - [Copy or move resources between projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md): the other resource types. --- # Copy or move an authentication setting > Copy an authentication setting into another project from Manage Resources, or move it together with every monitor that uses it. Tokens are not copied. Source: https://docs.apicontext.com/guides/projects/copy-or-move-an-authentication-setting Copy an authentication setting to use the same credentials setup in another project. Move it when the setting, and the monitors that use it, belong in another project. ## Prerequisites - At least Editor access to the setting's project, and Owner or Editor access to the destination project. - To move a setting, every monitor that uses it must be free to move: not on a schedule and not using a file. ## Steps Authentication settings have no Copy or Move button on their own page, so start from the sidebar. 1. In the sidebar, under **Project Administration**, select **Project Export / Import**. The **Manage Resources** page opens ([open it in the platform](https://client.apimetrics.io/manage)). 2. Under **Select the type of resource to copy or move**, choose **Authentication Setting**. 3. In **Select the Authentication Setting(s)**, pick one or more settings. 4. Under **Copy or Move**, select **Copy** or **Move**. 5. Choose the destination project. 6. Read the dry run that appears. ![Manage Resources with an authentication setting selected, Copy chosen, and the dry run warning that tokens will not be copied](https://docs.apicontext.com/img/manage-resources-copy-auth-setting.webp) 7. Select **Copy** or **Move**, then confirm. ## What carries over **Copy** copies the setting only. The dry run warns "Tokens WILL NOT be copied": the copy has no tokens, so create or fetch a token for it in the destination project before a monitor can use it. No monitors are copied with it. **Move** moves the setting, its tokens, and every monitor that uses it. Because those monitors move too, the move is blocked if any of them is on a schedule or uses a file. The dry run names each one. After the move, add the monitors to a schedule in the destination project. > **Move monitors in bulk** > > Moving an authentication setting is a quick way to move every monitor that uses it in one step. ## Next steps - [Monitor Authentication](https://docs.apicontext.com/guides/monitor-authentication.md): set up the token in the destination project. - [Copy or move a monitor](https://docs.apicontext.com/guides/projects/copy-or-move-a-monitor.md): copying a monitor to another project copies its authentication setting too. - [Copy or move resources between projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md): the other resource types. --- # Copy or move resources between projects > Open Manage Resources from the sidebar or from the Copy and Move buttons, then copy or move monitors, authentication settings, workflows, and reports. Source: https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects Copy a monitor, authentication setting, workflow, or report into another project, or into the same project as a duplicate. Move one when it should live in a different project instead. Both happen on the **Manage Resources** page. ## Prerequisites - At least Editor access to the project you copy or move from. Without it, Manage Resources shows a message that edit access is needed instead of the form. See [Access Roles](https://docs.apicontext.com/concepts/access-roles.md). - Owner or Editor access to the project you copy or move to. Only those projects appear in the destination list. ## Open Manage Resources There are two ways in. **From the sidebar.** Under **Project Administration**, select **Project Export / Import**. The link does not say "Manage Resources", but the page it opens is titled **Manage Resources** ([open it in the platform](https://client.apimetrics.io/manage)). ![Sidebar Project Administration section with Users and Admins, Audit Logs, and the Project Export / Import link highlighted](https://docs.apicontext.com/img/manage-resources-sidebar-path.webp) **From the resource itself.** Monitor pages, workflow pages, and report pages have **Copy** and **Move** buttons in the action bar under the page title. Each one opens Manage Resources with that resource already selected. Authentication settings have no Copy or Move button, so use the sidebar for them. ![Monitor Edit page action bar with Create Report, Copy, and Move, with Copy and Move highlighted](https://docs.apicontext.com/img/monitor-copy-move-buttons.webp) ## Copy or move a resource 1. Under **Select the type of resource to copy or move**, choose **Monitor**, **Authentication Setting**, **Workflow**, or **Report**. ![Manage Resources resource type list open with Monitor, Authentication Setting, Workflow, and Report](https://docs.apicontext.com/img/manage-resources-type-picker.webp) 2. Pick one or more resources of that type. You can select several at once. 3. Under **Copy or Move**, select **Copy** or **Move**. 4. Choose the destination project. To duplicate a resource in the project it is already in, pick that project. 5. Read the check that appears. As soon as you pick a destination, Manage Resources does a dry run and lists what will happen: what will be copied or moved with the resource, what will not be copied, and anything that blocks the operation. A blocked move shows the reason in red and keeps the **Move** button disabled. A report shows nothing here: it has no dry run. 6. Select **Copy** or **Move**, then confirm. Each resource type carries different things with it. The how-to for each type says what: - [Copy or move a monitor](https://docs.apicontext.com/guides/projects/copy-or-move-a-monitor.md) - [Copy or move an authentication setting](https://docs.apicontext.com/guides/projects/copy-or-move-an-authentication-setting.md) - [Copy or move a workflow](https://docs.apicontext.com/guides/projects/copy-or-move-a-workflow.md) - [Copy or move a report](https://docs.apicontext.com/guides/projects/copy-or-move-a-report.md) > **Moving many monitors at once** > > Moving an authentication setting or a workflow moves every monitor that uses that setting or is in that workflow. Manage Resources says so at the top of the page. ## Next steps - [Export or import a project](https://docs.apicontext.com/guides/projects/export-or-import-an-apimetrics-project.md): copy a whole project as a JSON or YAML file. The Project Export and Project Import panels are on the same page, below the copy and move form. - [Schedules](https://docs.apicontext.com/concepts/schedules.md): why a copied or moved monitor needs a schedule in its new project. --- # Export or Import a Project > How to back up an APImetrics project to JSON or YAML, including alerts, webhooks, and token headers, and restore it through Project Import. Source: https://docs.apicontext.com/guides/projects/export-or-import-an-apimetrics-project > **Tip** > > Project export produces human-readable JSON or YAML that can be version-controlled and shared across environments. The file contains secrets, so keep it in a private repository. This is part of APIContext's [configuration as code](https://apicontext.com/features/configuration-as-code) approach: define monitoring in files, keep them in version control, and deploy through CI/CD. ## Project Export The Project Export feature enables you to create a complete backup of your project, including all configured alert and webhook settings, environment values, and token header values. You can choose to export in either JSON or YAML format. > **Protect the export file** > > An export contains secrets, including token header values. Store the file in a secure location, share it only with people who need it, and never commit it to a public repository. To prevent accidental duplication of resources when importing an exported file back into the same project, we recommend using the "Tag Project" button to assign unique internal identifiers to your resources. This helps maintain data integrity and avoid conflicts. ![Project Export](https://docs.apicontext.com/img/495a70a3b730bf8afb7a32868d46f3eb5192f22e4b37a7250608541ceaee3207-image.webp) ## Project Import The Project Import feature allows you to restore a previously exported APImetrics project. To begin, click the "Choose file" button to select your exported project file (either JSON or YAML format). Then, complete the process by clicking the corresponding "Upload JSON" or "Upload YAML" button. This will import the project's configuration, including alert settings, environment values, and token headers, back into the APImetrics platform. ![Project Import](https://docs.apicontext.com/img/837945922ef027189007e4e8c609cb7d6b58a58d9484a2a518d621205c380b71-image.webp) After successfully importing your project file, navigate to the Project Home page to begin accessing your imported resources. --- # Organize monitors across projects > Guidance on how many monitors to keep in one project, and how to spread a large deployment across several projects. Source: https://docs.apicontext.com/guides/projects/organize-monitors-across-projects Monitors live in a [project](https://docs.apicontext.com/concepts/projects-and-collections.md), and a project is the unit you share, filter, and review. Keeping each project to a manageable number of monitors makes them easier to find and to check at a glance. ## Choose how many monitors to keep in a project Aim for about **100 monitors per project**. Treat this as guidance, not a limit. A large deployment, for example 1,000 to 1,500 monitors, works better spread across several projects than kept in one. Group the monitors by something your team uses to find them, such as an API, a team or an environment. ## Spread monitors across projects 1. Create a project for each group. See [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md). 2. Move or copy the monitors into the right project. See [Copying and moving APImetrics resources between projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md). A scheduled monitor must be unscheduled before it can be moved. 3. Check each project's monitor count and the group it holds. ## Result Each project holds a group of monitors that your team can find and review together. ## Next steps - [Projects and collections](https://docs.apicontext.com/concepts/projects-and-collections.md): how monitors, projects, and collections relate. - [Monitors](https://docs.apicontext.com/concepts/monitors.md): what a monitor is and what it holds. - [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md): the ways to create a project. --- # Downtimes > Create and manage downtime windows that pause scheduled Monitors during planned maintenance, including Organization-wide downtimes for all schedules. Source: https://docs.apicontext.com/guides/projects/downtimes A **downtime** is a window during which scheduled Monitors are paused, so planned maintenance does not generate false alerts or count against your conformance and quality results. Downtimes can be applied to an individual schedule, or set at the **Organization level** so that **all schedules respect** the same window. This is a task-oriented guide for working with downtimes. For the underlying REST API, the Org-level Downtime endpoints are documented in the API Reference and are cross-linked throughout this page. > **Note** > > Organization-wide downtimes are managed from **Organization settings**, which is an Enterprise-tier capability. See the [pricing page](https://apicontext.com/pricing) for plan availability. ## Downtime scopes | Scope | Where you set it | What it covers | |---|---|---| | **Per-schedule downtime** | On a schedule, via **Add Downtime** (and **New Downtime for all schedules** on the Schedules page) | A single schedule's runs during the window | | **Organization-wide downtime** | Organization settings → **Downtimes** tab | All schedules across the Organization: every schedule respects these windows | The Schedules page notes that **"All schedules will respect organization-wide downtimes."** Use an Organization-wide downtime for maintenance that affects every project; use a per-schedule downtime for a window that should only pause one schedule. ## Add a downtime from the Schedules page To pause a single schedule, use the **Add Downtime** action on that schedule's row. To pause every schedule, use **New Downtime for all schedules** on the Schedules page. Each downtime has a start and end (with timezone) and can repeat daily or weekly. For the full step-by-step on per-schedule downtime windows, including the daylight-saving and start-time adjustment behavior, see [Managing Project-Level Downtimes](https://docs.apicontext.com/guides/setting-and-managing-schedules/managing-project-level-downtimes.md). > **Note** > > Use the [Create Org-level Downtime](https://docs.apicontext.com/reference/api-v3/create-org-level-downtime) API reference for the authoritative request schema. ### Find a downtime ID Every downtime on a schedule has a unique ID. You need it to read, update, or delete the downtime through the API. 1. Open the [Schedules](https://client.apimetrics.io/schedules) page and find the schedule. Its downtimes are listed after **Scheduled Downtimes:**. 2. Select **More info** to open the **Downtimes** table. It shows **Start Time**, **End Time**, **Repeat**, and **Actions**. 3. In **Actions**, select **Copy ID** to copy the ID to your clipboard. The button changes to **ID Copied** to confirm. 4. To see the ID in the table, select **Select Columns**, then turn on **Downtime ID**. The ID is the `downtime_id` in the [Get a downtime window](https://docs.apicontext.com/reference/api-full/get-schedule-downtime), [Update a downtime window](https://docs.apicontext.com/reference/api-full/update-schedule-downtime), and [Delete a downtime window](https://docs.apicontext.com/reference/api-full/delete-schedule-downtime) endpoints. ## Manage Organization-wide downtimes Organization-wide downtimes are listed and managed from **Organization settings → Downtimes**. These windows apply across the Organization, and all schedules respect them. To manage Organization-wide downtimes: 1. Open **Organization settings** for your Organization. 2. Select the **Downtimes** tab to view existing Organization downtime windows. 3. Add, edit, or remove windows as needed. ## Managing downtimes with the API Org-level downtimes have a full CRUD surface in the REST API. You can list, create, update, and delete downtime configurations across your Organization's projects. | Task | API Reference (Try-It) | Endpoint guide | |---|---|---| | List all Org-level downtimes | [List Org-level Downtimes](https://docs.apicontext.com/reference/api-v3/list-org-level-downtimes) | [List Org-level Downtimes](https://docs.apicontext.com/reference/org-level-downtimes/list-org-level-downtimes.md) | | Create a downtime across one or more projects | [Create Org-level Downtime](https://docs.apicontext.com/reference/api-v3/create-org-level-downtime) | [Create Org-level Downtime](https://docs.apicontext.com/reference/org-level-downtimes/create-org-level-downtime.md) | | Update an existing downtime | [Update Org-level Downtime](https://docs.apicontext.com/reference/api-v3/update-org-level-downtime) | [Update Org-level Downtime](https://docs.apicontext.com/reference/org-level-downtimes/update-org-level-downtime.md) | | Delete a downtime | [Delete Org-level Downtime](https://docs.apicontext.com/reference/api-v3/delete-org-level-downtime) | [Delete Org-level Downtime](https://docs.apicontext.com/reference/org-level-downtimes/delete-org-level-downtime.md) | These endpoints require a valid Access Token. See the [Device Code Authorization Flow](https://docs.apicontext.com/guides/device-code-auth.md) for obtaining one. ## See also - [Managing Project-Level Downtimes](https://docs.apicontext.com/guides/setting-and-managing-schedules/managing-project-level-downtimes.md): step-by-step per-schedule downtime windows. - [Setting and Managing Schedules](https://docs.apicontext.com/guides/setting-and-managing-schedules.md): how scheduling works and how downtimes interact with it. - [Org-level Integrations](https://docs.apicontext.com/guides/integrations/org-level-integrations.md): other Organization-level settings (Integrations, Certificates, Downtimes). - [List Org-level Downtimes](https://docs.apicontext.com/reference/api-v3/list-org-level-downtimes): full REST API reference for downtime CRUD. - [Pricing](https://apicontext.com/pricing): plan availability for Organization settings. --- # Create a service account > Create a service account for an organization, assign its access roles, and save the Client ID and Client Secret it generates. Source: https://docs.apicontext.com/guides/projects/create-a-service-account Service accounts allow Organization Admins to create non-user accounts that can authenticate with APImetrics APIs using OAuth client credentials. Choose a relevant name and assign one or more access roles from the roles available within the Organization. These roles determine what the service account can access. ## Prerequisites - The Organization Admin role: the **Service Accounts** section is available under **Accounts** for Organization Admins. ## Steps 1. Select the **Create Service Account** button. 2. Enter a relevant **Service Account Name**, then assign the appropriate **Access Roles** from the available Organization roles. 3. When ready, select **Create**. ![Create Service Account form with a name field, ADMIN and DEFAULT role tags, and Create and Cancel buttons](https://docs.apicontext.com/img/Org-Settings_Service_Accounts.webp) ## Result Once the service account has been created, APImetrics will generate a **Client ID** and **Client Secret**. Make sure to securely copy and store these credentials, as the Client Secret will not be shown again. You can also select **Download JSON** to download the credentials in JSON format. See [Generate an Access Token](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md#generate-an-access-token) to learn how to use these credentials to authenticate with the APImetrics API. ## Next steps - [Organizations](https://docs.apicontext.com/guides/projects/organizations.md): what each section of the organization's settings shows, including Roles and Accounts. - [Access Roles](https://docs.apicontext.com/concepts/access-roles.md): what the project roles allow. --- # Manage the emails APIContext sends you > Choose which emails you receive from APIContext, and turn the daily, weekly, and monthly status emails on or off for a Project. Source: https://docs.apicontext.com/guides/projects/manage-email-settings APIContext sends emails in groups, such as the Insights Report. You control two things: which groups of email you receive, and which status emails you receive for each Project. Both settings apply only to your own account and email address. An alert email goes to the address typed into an alert in Alerts & Webhooks. The alert decides who gets it; the **APImetrics Alert** group below only lets you stop alert emails to your own address. To change who an alert emails, see [Email alerts](https://docs.apicontext.com/guides/alerting/using-webhooks/email-alerts.md) and [Setting alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md). ## Prerequisites - An APIContext account that you can sign in to. - For project status emails, access to the Project. ## Choose which emails you receive 1. Open the user menu at the top right of the portal and select **Email Settings**, or go straight to [Email Settings](https://client.apimetrics.io/subscriptions/email). 2. Find the email group you want to change. Each group has a switch, a name, and a description. 3. Switch the group on to receive its emails, or off to stop receiving them. The change is saved when you move the switch. You do not need to select a save button. The page lists five groups, each with the description shown here: | Group | Description on the page | |---|---| | **Insights Reports** | Weekly and Monthly Insights reports, showing your APIs CASC scores | | **APImetrics Alert** | These emails are sent when there has been an alert relating to an API call | | **Daily Update** | Daily updates on the status of your API calls | | **Weekly Update** | Weekly updates on the status of your API calls | | **Project Updates** | Project-level updates | Switching off **Project Updates** stops the Project status emails for every Project. To stop them for one Project only, use its Daily, Weekly, and Monthly switches instead (below). ### Get emails again after you unsubscribed from a link The unsubscribe link in an APIContext email switches off that email's group for your address, the same as the switch on this page. To receive those emails again, open [Email Settings](https://client.apimetrics.io/subscriptions/email) and switch the group back on. ### What Insights Report emails are The Insights Report is a weekly email, sent to you and covering every Project you can access. Its subject starts with "CASC alerts for week beginning" and the date. It reports Monitors whose [CASC score](https://docs.apicontext.com/concepts/casc-score.md), shown in the portal as the Quality Score, changed notably during the week. If no Monitor has changed notably, APIContext does not send the email. Switching off the Insights Report group stops this email. It does not affect alert emails, and it does not change the CASC score of any Monitor. ## Choose which status emails you receive for a Project 1. Select the Project in the Project picker. 2. Open the [Project Settings page](https://client.apimetrics.io/settings/project). 3. In the **Project Email Settings** section, find **Project status emails**. 4. Switch **Daily**, **Weekly**, or **Monthly** on or off. You can turn on more than one. The change is saved when you move the switch. Each switch controls your own subscription to this Project only, so other users of the Project keep their own settings. To see what a status email looks like before the next one arrives, select **Send today's email** in the same section. APIContext sends you the Project's most recent daily status email. Its subject is the name of the Project and the date. ## Result Your Email Settings page shows each group of email as on or off. The Project Email Settings section shows which of the Daily, Weekly, and Monthly status emails you receive for that Project. ## Next steps - [Email alerts](https://docs.apicontext.com/guides/alerting/using-webhooks/email-alerts.md): send failure and warning alerts to an email address. - [CASC score](https://docs.apicontext.com/concepts/casc-score.md): how the Quality Score behind the Insights Report is calculated. - [Basic navigation](https://docs.apicontext.com/guides/basic-navigation.md): find the top navigation menu and the Project picker. --- # Projects > Your monitors, Authentication Settings, Insights, and Results are owned by a Project. Share access with other users at one of five access levels. Source: https://docs.apicontext.com/guides/projects ## The Basics... For what a project is and where projects appear, see [Project basics and access levels](https://docs.apicontext.com/concepts/project-basics-and-access-levels.md). Click 'Create Project' to create a new project\ Click on a project name to enter the project\ Click on the + to add a new API\ Click on the \* to favorite a project ![Collections page Personal Projects list with the Create new API Call tooltip and Create Project link](https://docs.apicontext.com/img/da0cf9b-new_project.webp "new project.png") To get the URL of a project's home page, select the link icon next to the project's star. Its tooltip reads "Copy the URL for this project to your clipboard". The tooltip changes to "Copied to clipboard" once the URL is copied. Paste the URL into a browser to open that project's home page. The same icon appears in the project list of an organization. When you're logged into a project, in the sidebar, the Project picker drop down lets you see which Projects you have access to. They are grouped alphabetically by access level. Selecting a Project will select it and let you view the data for it. ![Sidebar Project picker dropdown listing projects grouped by Owner access and View access](https://docs.apicontext.com/img/6634285-project_picker.webp "project picker.png") 'Collections' take you to the main Collections management page.\ The drop down picker will show you all the individual projects you have access to and your level of access. ## Project Access Levels A project has five access levels: Owner, Manager, Editor, Analyst, and Viewer. For what each one lets a user do, see [Access Roles](https://docs.apicontext.com/concepts/access-roles.md). ## Project Administration Project owners will see a [Admin] link next to the Project picker. This will lead you to the Project Administration page. The Project Admin page lets the owner of the Project invite other users to the project, or remove access from existing users.\ The existing users are listed by access level. If you want to upgrade or downgrade an existing user, use the Add... button make an account picker appear.\ Use the Create Invite... link to invite a user to access the project by their email address. Use the Access Level drop down to pick the access level for the invited user. When you press Invite, an email will be sent with a link to accept the invite.\ As well as the email, when they next log in to APImetrics with a matching account, they'll be reminded that the invite is waiting for them.\ The pending invites are listed below. They may be deleted before the invite is accepted. ![Project administration page listing users by access level with Create Invite and pending invites](https://docs.apicontext.com/img/2c08e1f-org_admin.webp "org admin.png") ## Creating a new project In the top bar, under the Project menu, is an option to create a new project. If you create a new project, you will be the owner. ![Collections page projects list with the Add Project link highlighted to create a new project](https://docs.apicontext.com/img/fb0504b-Screen_Shot_2020-04-29_at_5.23.07_PM.webp "Screen Shot 2020-04-29 at 5.23.07 PM.png") ## Deleting a project (**'Starter'** & **'Team'** plans): Users with 'Starter' or 'Team' subscriptions cannot delete projects directly through the portal. To delete your project, [contact support](https://apicontext.com/support). (**'Pro'** & **'Enterprise'** plans): 'Pro' or 'Enterprise' subscription users having either the Owner-level access to the project or Admin-level access to the Organization can delete the project directly from the Organization settings page within the portal. Note: Before deleting any project, ensure all roles and users associated with the respective project are revoked. --- # Switch organizations > Switch between the organizations you belong to from the account menu in the top bar, then open one of their projects. Source: https://docs.apicontext.com/guides/projects/switch-organizations If you belong to one or more [organizations](https://docs.apicontext.com/guides/projects/organizations.md), the account menu in the top bar lists them. Use it to move between them. ## Prerequisites - Membership of at least one organization. ## Steps 1. Click your profile picture at the top right of the top bar. 2. Below **Email Settings**, select the name of the organization. ## Result The organization's overview opens and lists its projects. To open one of your projects, use the project picker. ## Next steps - [Basic Navigation](https://docs.apicontext.com/guides/basic-navigation.md): a tour of the side and top navigation menus, including the project picker. - [Organizations](https://docs.apicontext.com/guides/projects/organizations.md): what each section of the organization's settings shows. - [Projects and Collections](https://docs.apicontext.com/concepts/projects-and-collections.md): how projects, collections, and organizations relate. --- # Remove a monitor from the monitored list > Use Always in not monitored list to keep a monitor out of the Monitors in Schedules table on the Project Overview. Source: https://docs.apicontext.com/guides/quality-analytics/omit-from-casc-score Use this guide when you want a monitor to stay out of the **Monitors in Schedules** table on the Project Overview. The setting is **Always in not monitored list**, and it applies to one monitor at a time. **Always in not monitored list** removes the monitor from that table. It is not the setting for conformance checks. To stop Schema and Security conformance checks on a monitor, use **Skip Conformance Checks** instead. See [Exclude APIs from Conformance checks](https://docs.apicontext.com/guides/conformance/exclude-conformance-monitoring.md). ## Find the monitor Go to the sidebar and select [Monitors](https://client.apimetrics.io/tests/). ![Monitor Edit page with the Monitors option highlighted in the Configure Monitoring sidebar](https://docs.apicontext.com/img/99f77c9-image.webp) From your list of monitors, select the one you want to remove from the monitored list. ## Turn on Always in not monitored list Go to the **Advanced** tab of the monitor. ![Monitor Edit page with the Advanced tab selected](https://docs.apicontext.com/img/5c260b6-image.webp) Scroll to the **Home page behavior** section. The section reads: "Control whether this Monitor should appear in the monitored list or not." It is shown for API monitors. It has two switches: - **Always in monitored list** - **Always in not monitored list** Turn on **Always in not monitored list**, then click **Save**. Turning on one switch turns the other off. ![Home page behavior section of the Advanced tab with the Always in not monitored list toggle highlighted](https://docs.apicontext.com/img/f4b8d56-image.webp) ## Result The monitor no longer appears in the **Monitors in Schedules** table on the Project Overview. To put the monitor back, turn off **Always in not monitored list**. ## Next steps - [Project Dashboard](https://docs.apicontext.com/guides/analytics/project-home.md): what the Project Overview shows. - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): what the quality score measures. --- # CASC Score > Curious how to improve your CASC score or personalise it to your needs? Follow our how-tos Source: https://docs.apicontext.com/guides/quality-analytics To understand what the CASC score measures, see [CASC Score concept](https://docs.apicontext.com/concepts/casc-score.md). To learn more about what your CASC score means, we have more information in [the CASC score reference](https://docs.apicontext.com/concepts/casc-score.md). Below are the tutorials we have for improving or personalising your CASC score: * [Remove a monitor from the monitored list](https://docs.apicontext.com/guides/quality-analytics/omit-from-casc-score.md) --- # Postman Collection Monitors > If you already have your API calls set up in Postman, no need to duplicate the setups in APImetrics Source: https://docs.apicontext.com/guides/working-with-postman/monitor-postman-collections If you have your monitors and tests in Postman[Postman](https://www.getpostman.com/), duplicating effort to add them to APImetrics can seem like a daunting task. To solve this problem, we offer the option to manage your collections in Postman but take advantage of running calls through our data centers (only available for Google, AWS, and Azure locations) and generate analysis and insight using APImetrics. For this to work, you will need to configure a Postman API key (which is covered in the [working with Postman guide](https://docs.apicontext.com/guides/working-with-postman.md)) AND generate an APImetrics API key - if you do not have an APImetrics API key, you can generate this when you link Postman and APImetrics. > **Importing APIs also available** > > If you'd rather import your API definitions from Postman or a variety of other formats, see the [Importing Monitors](https://docs.apicontext.com/guides/importing-api-calls.md) and [Importing from Postman](https://docs.apicontext.com/guides/importing-api-calls/importing-from-postman.md) pages. > **Postman Monitoring uses the Postman API** > > Make sure your Postman subscription has enough quota ## Setup To get started, on the Monitor Postman Collection page, click "Configure a new Postman Collection monitor". ![Configured Postman collections page with no collections monitored and a Configure a new Postman Collection monitor button](https://docs.apicontext.com/img/2c9f977-Screen_Shot_2019-08-08_at_11.19.22_AM.webp) You may need to generate an APImetrics API key - click "Generate Auth Settings" to continue. ![Configure a new Postman collection monitor screen prompting to generate APImetrics API authentications via Generate Auth Settings](https://docs.apicontext.com/img/b56893f-Screen_Shot_2019-08-08_at_11.19.40_AM.webp) ## Select your Collection and Environment ![Select your Postman Collection step listing available collections such as Problem APIs, Postman Echo and APImetrics APIs](https://docs.apicontext.com/img/20396f7-Screen_Shot_2019-08-08_at_11.20.27_AM.webp) Select the Collection you wish to monitor. On the next page select the Environment (if any) you wish to use. On the last page, there are some optional parameters you may add or change. Once happy, press "Create new monitor" to create the monitor. ![Optional Parameters form with globals, folder, timeout and redirect fields and a Create new monitor button](https://docs.apicontext.com/img/ed2421b-Screen_Shot_2019-08-08_at_11.21.02_AM.webp) The collection will appear under your Configured Postman collection list at the top. ![Configured Postman collections list showing the Postman Echo collection with a New Schedule option](https://docs.apicontext.com/img/25f37bf-Screen_Shot_2019-08-08_at_11.21.52_AM.webp) ## Start monitoring > **Schedule your collection** > > You must schedule the collection to start monitoring Select a schedule to start monitoring. The schedule must be a Postman-only schedule as the Postman monitors are only available on a sub-set of our locations. ![Schedule picker with the Postman Sched schedule selected and a delete button](https://docs.apicontext.com/img/e9ac548-Screen_Shot_2019-08-08_at_11.21.55_AM.webp) You can use the Add Schedule button to create a new schedule: ![Edit Schedule dialog setting name, frequency, regions and Postman-only Schedule toggled On](https://docs.apicontext.com/img/06dbe61-Screen_Shot_2019-08-08_at_11.22.03_AM.webp) Once the Collection monitoring starts, your account will be populated with the monitors in the collection, and the results will appear. Note that you cannot edit the monitors in APImetrics - you must save any changes to the Collection from Postman. > **Ensure timing accuracy** > > As we’re running the Postman Collections “natively”, it re-uses connections when running sequential calls in a collection. This means that will see DNS lookup, TCP connection time and SSL handshake values will appear as 0ms for subsequent monitors. In order to avoid that, add a “Connection: close” header to the monitors in the Collection. This is purely optional, but will mean we get more accurate timings. --- # Working with Postman > With APImetrics you can import direct from Postman OR run Postman collections through our agent network and use us to generate data. Source: https://docs.apicontext.com/guides/working-with-postman To start working with Postman, you will need to generate a Postman API Key - this can be hard to find inside Postman and they have some tricky rules in place around how you can copy and use it. This functionality is subject to change and we will work our hardest to keep on top of the Postman UI. Once a key is generated, you need to link Postman with your APImetrics project - this is achieved in the Import API menu in the left hand navigation. ## Generating a Postman API Key To generate your Postman API key you will need to find the 'settings' menu under the dropdown from your user name in the top right of the UX. ![Postman user dropdown menu with an arrow pointing to the Settings option](https://docs.apicontext.com/img/89340cb-Use_the_correct_settings.webp) Select "API Keys" ![Postman Account settings page with an arrow highlighting the API keys item in the left sidebar](https://docs.apicontext.com/img/485b983-API_Key_Settings.webp) In the next menu, select "generate API key" ![Postman API keys page with no keys yet and an arrow pointing to the Generate API Key button](https://docs.apicontext.com/img/c445f0c-Generate_API_Key.webp) Once generated, you will need to copy this for use in APImetrics. > **APImetrics CANNOT import the encrypted API key** > > The API keys are stored in Postman in an encrypted format. If you want to reuse an API key you will need to click on the 3 dots and select 'regenerate key' then COPY that for use. > **You cannot import a Postman Collection you have not saved** > > This will result in an import error. ## Linking your APImetrics Project with Postman Select "Import API" from the left hand navigation menu, click on 'Use Postman' ![APImetrics Import your APIs page with the Use Postman option for entering Postman details](https://docs.apicontext.com/img/29ffcb0-Start_with_Import.webp) Copy and paste the API key into the box and click Validate. ![Postman API key import step with a field to enter the key and a Validate button](https://docs.apicontext.com/img/3cfcc49-validate_key.webp) APImetrics will then sync your Postman collections. ## Importing monitors from Postman To import a collection to run and manage in APImetrics you select the collection. ![Pick Collection import step listing the synced Postman collection Example Calls to select](https://docs.apicontext.com/img/f5e1b8f-pick_collection.webp) Our system will then import the calls into a workflow and give you the option to update existing calls that might already be in your project. ![Preview Import step showing the workflow and API calls to be created or mapped to existing project calls](https://docs.apicontext.com/img/f107c9f-map_calls_or_update.webp) --- # Monitor Authentication > Configure authentication for your API monitors: OAuth 2, API keys, Bearer tokens, Mutual TLS, and custom flows. Source: https://docs.apicontext.com/guides/monitor-authentication APIContext's authentication manager lets you define reusable authentication settings that any monitor in your project can use. Configure it once, attach it to as many monitors as you need, and APIContext sends the credentials with every request. > **Note** > > Configuring Monitor Authentication requires the **EDITOR** role or higher. See [Access Roles](https://docs.apicontext.com/concepts/access-roles.md) for the full permission matrix. ## How it works Authentication in APIContext has two layers: | Layer | What it is | Where you manage it | |---|---|---| | **Auth Setting** | The credential configuration (OAuth app, API key, certificate) | **Configure Monitoring → Monitor Authentication** | | **Token** | The active credential derived from the setting (access token, key value) | On the Auth Setting's page, in its tokens table | When you attach an Auth Setting and a token to a monitor, APIContext injects the token into every request. It renews an expired OAuth 2 token that has a refresh token or uses the Client Credentials grant, and runs your refresh workflow for a Manual Setup token. Other tokens stay as they are until you change them. See [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md). ## Supported authentication types ### API Key Pass a static key in a header or query parameter. Use this for services that issue long-lived API keys. In the **Authentication Type** list, choose **API key in request / Manual Setup**. → [Setting up API key authentication](https://docs.apicontext.com/guides/authentication-settings/creating-an-authentication.md) ### Basic Auth Send a username and password in an `Authorization: Basic` header. Create the setting with the **Basic Auth** type, then add a token that holds the username and password. → [Set up Basic authentication](https://docs.apicontext.com/guides/monitor-authentication/set-up-basic-authentication.md) ### OAuth 2 (Authorization Code, Client Credentials, Device Code) APIContext handles the OAuth flow without any code. Configure the OAuth app details (Client ID, Secret, token URL, scopes) and APIContext renews the token when the provider issued a refresh token or you use the Client Credentials grant. Otherwise, sign in again when the token expires. → [Fundamentals of OAuth in APIContext](https://docs.apicontext.com/guides/authentication-settings/fundamentals-of-oauth.md) → [Example OAuth setup](https://docs.apicontext.com/guides/authentication-settings/example-oauth-authentication-set-up.md) → [Device Code authorization flow](https://docs.apicontext.com/guides/device-code-auth.md) → [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md) ### Fixed Bearer Token Provide a static Bearer token. APIContext passes it as `Authorization: Bearer <token>` on every request. No refresh; rotate manually. ### Custom authentication (Manual) For non-standard flows, use the **API key in request / Manual Setup** type to specify exact headers and parameters per token, save extracted values as variables, and use `EXPIRES_IN` to drive refresh. → [Custom authentication](https://docs.apicontext.com/guides/advanced-authentication/custom-authentication.md) ### Mutual TLS (mTLS) Attach a client certificate to an Auth Setting to authenticate at the TLS layer. Upload your certificate under **Certificates** first. → [Handling Mutual TLS](https://docs.apicontext.com/guides/advanced-authentication/mutual-tls.md) → [Upload a signing certificate](https://docs.apicontext.com/guides/authentication-settings/certificates/upload-a-signing-certificate.md) ## Authentication in workflows To use a token obtained in one monitor as input to subsequent monitors, use a workflow. A monitor POSTs to the token endpoint and captures the token via Conditions. The captured value is saved as a variable into the Auth Token. Downstream monitors in the workflow use that variable. The steps are in the guide below. → [Authentication in a workflow](https://docs.apicontext.com/guides/authentication-settings/authentication-in-a-workflow.md) ## The basics New to authentication settings? Start here: → [The Basics: auth settings and tokens](https://docs.apicontext.com/guides/authentication-settings/basics-of-authentication-settings-and-tokens.md) ## See also - [Access Roles](https://docs.apicontext.com/concepts/access-roles.md): who can create and edit Auth Settings - [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md): restore monitoring when a credential lapses - [Set conditions on a monitor](https://docs.apicontext.com/guides/set-conditions.md): extract values for use as variables - [Copy or move an authentication setting](https://docs.apicontext.com/guides/projects/copy-or-move-an-authentication-setting.md): reuse a setting in another project, or move it with its monitors --- # Set up Basic authentication > Create a Basic Auth setting with a username and password token, and attach it to a monitor so every request carries the credentials. Source: https://docs.apicontext.com/guides/monitor-authentication/set-up-basic-authentication Use Basic authentication when the API you monitor expects a username and password. You create a **Basic Auth** setting for the API's domain, store the credentials in a token, and select that setting and token on each monitor that needs them. APIContext then sends an `Authorization: Basic` header on every request the monitor makes, built from the username and password in the token. ## Prerequisites - The **EDITOR** role or higher in the project. The **Monitor Authentication** menu item only appears for editors. See [Access Roles](https://docs.apicontext.com/concepts/access-roles.md). - The domain of the API, for example `api.example.com`, and the username and password it accepts. - A monitor that calls that API, or the intention to create one. See how to [add a monitor](https://docs.apicontext.com/guides/add-a-monitor/add-api-call.md). ## Steps 1. Open [Monitor Authentication](https://client.apimetrics.io/auth/) from **Configure Monitoring** in the left menu, then click **Add new Auth Setting**. 2. In the **Create Authentication** panel, fill in the fields: - **Name**: a label of at least 3 characters, for example `Example API Basic`. - **Endpoint Domain**: the plain domain name with no slashes, for example `api.example.com`. - **Authentication Type**: select **Basic Auth**. The other fields on the panel are informational or apply to other types. **Basic Auth** has no Client ID, Client Secret, or URL fields. You cannot change the type after you save the setting. 3. Click **Save**. APIContext opens the new setting's page, which shows an empty tokens table. 4. Click **Add New Token**. In the **Add New Token** panel, fill in the fields: - **Name**: a label of at least 3 characters, for example `Example API production user`. - **Username**: the username the API expects. - **Password**: the password for that username. The field is masked. **Domain** is read-only and is filled in from the setting. 5. Click **Save**. The token appears in the tokens table. 6. Open the monitor that calls the API, expand its **Authentication** section, and choose the setting you created in the list that shows **Select an Auth Setting**. Then choose your token in the list that shows **Select a Token**. 7. Save the monitor. ## Result The monitor sends the credentials on every request. After its next run, the result shows your API's response. A `401` status code means the API rejected the credentials: open the setting's page, click the token's row, correct the **Username** or **Password**, and click **Save**. Monitors that use the token pick up the change without further edits. A Basic Auth token has no expiry, so its **Expires** column shows **Never**. Update the token whenever the password changes at the API. For tokens that do expire, see [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md). > **Note** > > The **Use Basic Auth for Get Token API** switch on an OAuth 2 setting is a different feature. It controls how APIContext calls the provider's token endpoint, and it does not add Basic authentication to your monitors. ## Next steps - [Monitor Authentication](https://docs.apicontext.com/guides/monitor-authentication.md): every authentication type and how settings and tokens fit together. - [Authentication Model](https://docs.apicontext.com/concepts/authentication-model.md): why APIContext separates settings from tokens. - [Troubleshoot expired authentication tokens](https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens.md): restore monitoring when a credential lapses. --- # Troubleshoot expired authentication tokens > Find out why an authenticated monitor fails after a token or certificate expires, and restore monitoring for each token type and expiry mode. Source: https://docs.apicontext.com/guides/monitor-authentication/troubleshoot-expired-authentication-tokens An authenticated monitor starts failing, often with a `401` status code, because the credential it sends has expired or been rejected. Use this guide to confirm that the token is the cause, then fix it for the way your token expires: an OAuth 2 refresh token, a Client Credentials grant, a refresh workflow, a credential that never expires, or a certificate. ## Prerequisites - The **EDITOR** role or higher in the project. See [Access Roles](https://docs.apicontext.com/concepts/access-roles.md). - The name of the authentication setting and token the failing monitor uses. Open the monitor, expand its **Authentication** section, and read the **Select an Auth Setting** and **Select a Token** lists. ## Steps ### 1. Confirm the token has expired 1. Open [Monitor Authentication](https://client.apimetrics.io/auth/) from **Configure Monitoring** in the left menu, then click the setting your monitor uses. 2. In the tokens table, find the token. The **Expires** column shows the expiry date and time, and the **Expires In** column shows the time remaining, or **Expired** once the time has passed. Both columns show **Never** when APIContext holds no expiry for the token. 3. Click the token's row to open **Edit Token**. When the token has an expiry, the **Expires** badge reads **Expired** or **Active** with the date. APIContext treats a token as expired slightly before its listed time, so that it can renew the token before the API rejects it. If the token is **Active**, the cause is probably not expiry: check the username, password, or key the token holds. If it shows **Never** and the API still rejects it, go to [Token shows Never but the API rejects it](#token-shows-never-but-the-api-rejects-it). ### 2. Fix the token for its expiry mode Open the token and look at its fields to tell which case applies. OAuth 2 tokens show **Grant Type**, **Access Token**, **Expires In (seconds)**, and **Refresh Token**. Tokens on an **API key in request / Manual Setup** setting, called Manual Setup in this guide, show **Headers** and **Parameters**. Basic Auth tokens show **Username** and **Password**. #### OAuth 2 token with a refresh token When a monitor runs and finds the token expired, APIContext sends the **Refresh Token** to the setting's **Get Token URL** and saves the new **Access Token**, the new expiry, and any new **Refresh Token** the provider returns. You do not need to do anything when this works. If the token stays expired, the renewal failed. The usual causes are that the provider revoked the refresh token, that it expired, or that a newer one replaced it (some providers issue a new refresh token each time). 1. On the setting's page, click **Edit** and check **Get Token URL**, **Client ID**, and **Client Secret** against the app you registered with the provider. 2. If those are correct, [get a new token](#3-get-a-new-token-from-the-provider) and [point your monitors at it](#4-point-monitors-at-the-new-token). #### OAuth 2 token without a refresh token If the **Refresh Token** field on a token that uses the **Authorization Code** grant is empty, APIContext cannot renew it. The token works until its expiry, and then the monitor fails until someone signs in again. 1. [Get a new token from the provider](#3-get-a-new-token-from-the-provider) and [point your monitors at it](#4-point-monitors-at-the-new-token). 2. If the provider returns a refresh token during sign-in, APIContext stores it on the new token and renews it automatically from then on. Check the provider's documentation for how to request one. #### OAuth 2 token with the Client Credentials grant When a monitor finds a **Client Credentials** token expired, APIContext requests a new token from the **Get Token URL** using the setting's **Client ID** and **Client Secret**. No sign-in is needed. If the token stays expired, the provider rejected the request. 1. On the setting's page, click **Edit** and check **Get Token URL**, **Client ID**, and **Client Secret**. 2. Click **Add New Token**, choose **Client Credentials** as the **Grant Type**, and click **Get Token**. If the provider rejects the request, the panel shows its error. 3. When it succeeds, [point your monitors at the new token](#4-point-monitors-at-the-new-token). #### Manual Setup token renewed by a workflow A **Manual Setup** token expires only when a workflow saves an `EXPIRES_IN` value into it. See [Custom authentication](https://docs.apicontext.com/guides/advanced-authentication/custom-authentication.md#refreshing-tokens-automatically). The setting's page shows a **Refresh Token Workflow** row when one is set. When a monitor finds the token expired, it stops, APIContext runs that workflow, and the monitor then resumes. APIContext tries the workflow once for each run. If the token is still expired afterward, the monitor runs with the old values and fails. 1. Run the refresh workflow yourself and open the token afterward. **Expires** must show a new, later time. 2. If it does not, check that the workflow saves the new values into this token with a **Save Auth Token** webhook, and that it saves an `EXPIRES_IN` value. See [Saving variables into an Auth Token](https://docs.apicontext.com/guides/advanced-authentication/custom-authentication.md#saving-variables-into-an-auth-token). 3. If the setting shows no **Refresh Token Workflow** row, APIContext has nothing to run when the token expires. Click **Edit** on the setting and select the workflow in **Refresh Token Workflow**. #### Token shows Never but the API rejects it APIContext records an expiry only when the provider's response includes an `expires_in` or `expires` value, or when you enter **Expires In (seconds)** on the token. Without one, APIContext does not know the token has lapsed and never renews it, even when it holds a refresh token. 1. Look up the token lifetime in the provider's documentation. 2. On the setting's page, click **Add New Token**, then click **Enter token values manually**. Enter a **Name**, the **Access Token**, the **Refresh Token** if you have one, and the lifetime in **Expires In (seconds)**, then click **Save**. 3. [Point your monitors at the new token](#4-point-monitors-at-the-new-token). #### API key, fixed bearer token, or Basic Auth Tokens on a **Manual Setup** setting that no workflow updates, and Basic Auth tokens, have no expiry in APIContext, so **Expires** shows **Never**. They stop working only when the issuer changes or revokes the credential. Click the token's row, enter the new value in **Headers**, **Parameters**, **Username**, or **Password**, and click **Save**. Monitors that use the token pick up the change without further edits. For Basic Auth, see [Set up Basic authentication](https://docs.apicontext.com/guides/monitor-authentication/set-up-basic-authentication.md). #### Signing key or client certificate Certificates for RSA signing and for Mutual TLS are stored once for the organization, and each shows an **Expires** date on the **Certificates** tab of your organization settings. The date is highlighted as a warning when 60 days or fewer remain, and as a failure once it has passed. Check this tab before the date arrives. 1. Select the certificate's row and replace the **Certificate** and **Private Key**, as described in [Certificates](https://docs.apicontext.com/guides/authentication-settings/certificates.md#update-a-certificate). Update the existing certificate rather than adding a second one, so that settings that already use it keep working. 2. Allow time for the change. APIContext caches certificates, and a new one can take an hour or more to come into use. ### 3. Get a new token from the provider Do this only when step 2 sends you here. 1. On the setting's page, click **Add New Token**. 2. Enter a **Name** of at least 3 characters. Choose the **Grant Type** (normally **Authorization Code** for user sign-in) and enter the **Scope** if the provider needs one. 3. Click **Authenticate with** followed by the setting's name. The provider's sign-in page opens. The provider may need the **Callback URL** shown in the panel registered with your app. 4. Sign in and approve access. The provider returns you to APIContext, which saves the new token. ### 4. Point monitors at the new token Getting a new token from the provider creates a separate token. Monitors keep using the token they have selected until you change it. 1. Open each monitor that used the old token, expand **Authentication**, and choose the new token in the list that shows **Select a Token**. 2. Save the monitor. ## Result The failing token's replacement shows a later time in **Expires** and a remaining time in **Expires In**, and **Edit Token** shows **Active**. After the next run, the monitor's result shows your API's response instead of the authentication failure. ## Next steps - [Monitor Authentication](https://docs.apicontext.com/guides/monitor-authentication.md): every authentication type and how settings and tokens fit together. - [Authentication Model](https://docs.apicontext.com/concepts/authentication-model.md): why settings and tokens are separate, and how tokens are refreshed. - [Fundamentals of OAuth](https://docs.apicontext.com/guides/authentication-settings/fundamentals-of-oauth.md): set up the OAuth app, callback URL, and first token. - [Custom authentication](https://docs.apicontext.com/guides/advanced-authentication/custom-authentication.md): build a refresh workflow for a Manual Setup token. --- # SLO and SLA Management > Set Service Level Objectives and Performance Change Thresholds for a project in Conformance Settings, and see where SLO results appear. Source: https://docs.apicontext.com/guides/slo-management APIContext lets you define **Service Level Objectives (SLOs)** for a project and track whether its monitors meet them. For an overview of SLO/SLA capabilities, see [SLO/SLA Management](https://apicontext.com/features/api-sla-and-slo-management) on the platform site. For background on SLOs, SLAs, and how they relate to the CASC Quality Score, see [SLA Model](https://docs.apicontext.com/concepts/sla-model.md). ## What you can configure SLOs are set per project. Each one is a metric and a threshold: | Group | Metrics | |---|---| | **Core Metrics** | Availability, Pass Rate (greater than); Slow Rate, Warning Rate, Fail Rate (less than); DNS Lookup, TCP Connect, SSL Handshake, Network time, Upload time, Processing time, Download time, Server time, Total latency excluding DNS, Total latency (less than); Quality score, Apdex score (greater than) | | **Core Web Vitals** | For browser monitors | **Performance Change Thresholds** catch a monitor getting worse even while it still meets its SLOs: | Threshold | Unit | |---|---| | **Decrease in pass / fail grade** | percentage points | | **Increase in any latency component** | milliseconds or percent | ## Setting up an SLO ### Step 1: Open the SLO settings 1. Open [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings): in the left sidebar, select **Conformance**, then the **Settings** tab. 2. Find the **Manage Service Level Objectives and Performance Change Thresholds** section. ### Step 2: Add an SLO 1. Under **Service Level Objectives**, pick a metric from **Core Metrics** (or **Core Web Vitals**). 2. Set the threshold, for example **Availability greater than** 99.9 percent, or **Quality score greater than** 8. 3. Click **Add SLO**, then **Save**. For the Quality score scale, see [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): | Range | Health status | |---|---| | 8.00 – 9.99 | Healthy | | 5.00 – 7.99 | Degraded | | 0 – 4.99 | Critical | ### Step 3: Add a Performance Change Threshold 1. Under **Performance Change Thresholds**, choose **Decrease in pass / fail grade** or **Increase in any latency component**. 2. Set the amount and unit. 3. Click **Add Threshold**. To return every SLO in the project to the defaults, use **Reset SLOs in Project** and confirm. ### Step 4: Get alerted and check results - **Alerts.** Set up notifications in [Alerts & Webhooks](https://client.apimetrics.io/webhooks) (under **Configure Monitoring** in the sidebar). See [Setting up alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md). - **Results.** The [Conformance Summary](https://client.apimetrics.io/governance/conformance/summary) has a row each for **Availability SLOs**, **Performance SLOs**, and **Performance Thresholds**, with pass or fail and issue counts. Use **Download as CSV** for SLA reporting. ## Edit or delete an SLO You can change or remove an SLO at any time. Both changes apply to the project's SLOs, not to individual monitors. 1. Open the **Manage Service Level Objectives and Performance Change Thresholds** section of Conformance Settings, as in [Step 1](#step-1-open-the-slo-settings). 2. Under **Service Level Objectives**, find the SLO in **Core Metrics** or **Core Web Vitals**. Each row shows the metric, its threshold, and, for most metrics, the unit. 3. To edit the SLO, change the threshold in the row. You can also pick a different metric or unit from the same row. The row shows a message if the value is out of range, for example "Please enter a whole number between 0 and 120000" for a latency threshold. 4. To delete the SLO, select the red trash icon at the end of its row. 5. Click **Save**. The button is available once you have changed something and every value is valid, and an edit or a delete takes effect only after you save. Performance Change Thresholds work the same way: edit the amount or select the trash icon, then click **Save**. ## See also - [SLA Model](https://docs.apicontext.com/concepts/sla-model.md): concept background - [Setting up performance SLOs, SLAs, and thresholds](https://docs.apicontext.com/guides/conformance/setting-up-performance-slos-slas-and-thresholds.md) - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): how the Quality Score is calculated - [Conformance overview](https://docs.apicontext.com/guides/conformance.md) - [Setting up alerts](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md) --- # Concepts > Core APIContext concepts, terminology, scoring, security, projects, and service-level objectives. Source: https://docs.apicontext.com/concepts Learn the core ideas behind APIContext: quality scoring, conformance, security profiles, projects and collections, locations, and service-level objectives. Browse the categories in the sidebar to understand how the platform models and evaluates your applications and services. --- # Monitors > What monitors are in APIContext and the three monitor types: API, Browser, and MCP. Source: https://docs.apicontext.com/concepts/monitors A **monitor** is a configured request that APIContext runs on your behalf from remote cloud locations around the world. Each monitor defines what to call, how to call it, and what a correct response looks like. When a monitor runs, APIContext records the full result (HTTP status, latency breakdown, headers, and body) so you can track health over time. ## Three types of monitor APIContext supports three monitor surfaces: | Type | What it tests | |------|---------------| | **API monitor** | A single HTTP request (any method) against a REST, GraphQL, or SOAP endpoint | | **Browser monitor** | A headless browser session that loads a page and captures Core Web Vitals and rendering performance | | **MCP monitor** | A request to an MCP (Model Context Protocol) server, testing AI infrastructure availability and correctness | All three types share the same scheduling, alerting, and results infrastructure. You can mix them freely within a project and combine them into [workflows](https://docs.apicontext.com/concepts/workflows.md) to test multi-step business processes. ## How monitors fit together Monitors are the atomic unit of observability in APIContext. Everything else builds on them: - **Schedules** control when and where monitors run - **Conditions** define what counts as a pass, warning, or failure - **Alerts** notify you when a condition is triggered - **Results** store the outcome of every execution A monitor on its own is a definition. It only produces data when you run it manually or attach it to a schedule. ## See also - [Monitor your first API](https://docs.apicontext.com/monitor-your-first-api.md): end-to-end tutorial from creating a project to reading results - [Add a monitor](https://docs.apicontext.com/guides/add-a-monitor.md): detailed guide to creating each monitor type - [Browser monitors](https://docs.apicontext.com/guides/add-a-monitor/browser-monitors.md): setting up browser monitoring - [MCP monitors](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors.md): monitoring MCP servers --- # CASC Score (Quality Score) > How APIContext calculates the 0–9.99 quality score for your API monitors. Source: https://docs.apicontext.com/concepts/casc-score The **CASC score** (displayed in the UI as **Quality Score**) is a single number between **0 and 9.99** that summarizes how consistently a monitor or project has passed and how fast and steady its responses have been. ## What the number means | Range | Meaning | |-------|---------| | 8.00–9.99 | Healthy | | 5.00–7.99 | Degraded: some failures, outliers, or latency spikes | | 0–4.99 | Critical: significant failure rate or very slow responses | Each project starts with a Quality score SLO of **greater than 7.99** over a month. You can change it in [Conformance Settings](https://docs.apicontext.com/guides/slo-management.md); see [SLA Model](https://docs.apicontext.com/concepts/sla-model.md) for how SLOs are checked. ## What feeds into the score The score is calculated and aggregated across all locations. Four signals feed each location's score: 1. **Pass rate:** the share of results that passed 2. **Outlier rate:** the share of results flagged as outliers 3. **Mean latency:** the average response time of passing results 4. **Latency spread:** how much that response time varies from run to run (its standard deviation) The exact weighting of these signals is proprietary and includes additional elements. **Conformance is not an input.** Schema and security conformance results do not change the score. They are reported separately (see [Conformance Explained](https://docs.apicontext.com/concepts/conformance-explained.md)), so turning on **Skip Conformance Checks** does not change a monitor's score. Your SLO targets are not inputs either: the score is calculated from results, and a Quality score SLO compares it to a target afterward. ## Quality Score vs CASC Score The **CASC Score** (Cloud API Service Consistency) is the technical name; the **Quality Score** is the name shown in the UI. They refer to the same value. Older documentation and API responses may use `casc_score` in JSON fields. For the full methodology and how CASC enables API quality benchmarking, see [What is CASC?](https://apicontext.com/what-is-casc) on the platform site. ## Where to find it - **Project overview**: aggregate score across all monitors in the project - **Individual monitor**: score for that monitor's recent run history - **Quality Analytics**: detailed breakdown of score drivers ## See also - [SLA Model](https://docs.apicontext.com/concepts/sla-model.md): how SLOs, including the Quality score SLO, are checked - [Conformance Explained](https://docs.apicontext.com/concepts/conformance-explained.md): conformance results, reported separately from the score - [Quality Analytics guide](https://docs.apicontext.com/guides/quality-analytics.md): working with the score in practice --- # FDX API 5.3 > Learn what the FDX API 5.3 standard is and how APIContext tests your API against its FAPI-based security checkpoints. Source: https://docs.apicontext.com/concepts/security-profiles/fdx-api-53 Financial Data Exchange (FDX) is an industry body that publishes a common technical standard for sharing consumer-permissioned financial data between banks, data aggregators, and apps. The Financial-Grade API (FAPI) Security Specification v3.4 from FDX is the companion to FDX API v5. It builds on the FAPI 1.0 Advanced and CIBA protocols to secure traffic to an API and to authenticate its end users. The FDX API 5.3 profile tests against that security specification. It applies to APIs that expose financial data through FDX. When a monitor calls your authorization, token, or resource endpoints, APIContext checks the traffic against a series of checkpoints, from the authorization request through to the resource server response: nine for the No PAR variants and eight for the PAR variant. The checkpoints below describe what each one looks at. Our implementation of FDX API 5.3 is split into checkpoints, each having multiple checks to confirm whether a particular observation is compliant. This security profile requires you to include your valid MTLS certificate on all the API requests, excluding requests to authorize an endpoint. To use this profile, select one of its three variants in the **Manage Standards Profiles** section of [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings): **FDX API 5.3 (No PAR, MTLS)**, **FDX API 5.3 (No PAR, Private Key JWT)**, or **FDX API 5.3 (PAR)**. ## No PAR ## Checkpoint 1 ### Authorization Request Checks These checks only apply to calls classified as sent to or from the Authorization endpoints and will be looking at the request to these endpoints to ensure the correct information is in the query parameters. ## Checkpoint 2 ### Request JWT Schema Checks These checks only apply to calls classified as sent to or from the Authorization endpoints and will be looking at the request JWT to these endpoints to ensure the correct information is in the headers, parameters, and payload. ## Checkpoint 3 ### Authorization Response Checks These checks only apply to calls classified as sent to or from the Authorization endpoints and will be looking at the responses from these endpoints to ensure the correct information is in the URL fragments. ## Checkpoint 4 ### id\_token JWT Schema Checks These checks apply to calls classified as sent to or from the Authorization endpoints and the Access Token endpoints and will be looking at the id\_token JWT to ensure the correct information is in the payload. ## Checkpoint 5 ### Token Endpoint Request Checks These checks only apply to calls classified as sent to or from the Access Token endpoints and will be looking at the requests to these endpoints to ensure the correct information is in the headers and parameters and that the correct HTTP method is being used. ## Checkpoint 6 ### Token Endpoint Response Checks These checks only apply to calls classified as sent to or from the Access Token endpoints and will be looking at the responses from these endpoints to ensure the correct information is in the headers and parameters. ## Checkpoint 7 ### Access Token Validation These checks apply to calls classified as sent to or from the Access Token endpoints and the Resource server and will be looking at the access\_token JWT to ensure the correct information is in the header and payload. ## Checkpoint 8 ### Resource Server Request Checks These checks only apply to calls classified as sent to or from the Resource server and will be looking at the requests sent to this server to ensure the correct information is in the header. ## Checkpoint 9 ### Resource Server Response Checks These checks only apply to calls classified as sent to or from the Resource server and will be looking at the responses from this server to ensure the correct information is in the header and the server returns the correct response code. ## PAR The PAR version of FDX API 5.3 follows the same checkpoints as the No PAR version but skips Checkpoint 2 as there is no JWT for calls using this method. --- # System Variables > APImetrics provides a range of pre-defined variables to automate certain aspects of API making calls. Source: https://docs.apicontext.com/concepts/environment-variables/apimetrics-defined-variables ## Key Concepts APImetrics provides a number of pre-defined system variables that can be used in a monitor. > **Syntax** > > Variables can be injected into a call by surrounding the variable name by either percentages (e.g. `%%NAME%%`) or double underscores (e.g. `__NAME__`). For use in a URI, we recommend double underscore. ## System Variables | Variable Name (`%%VAR_NAME%%` or `__VAR_NAME__`) | Description | | --- | --- | | `DATETIME` | A date string in ISO format, e.g.: 2019-07-09T19:29:43.492000 | | `DATE` | Returns the date only, e.g.: 2019-05-04 | | `TIME` | Returns the time string only, e.g.: 14:34:45 | | `PROJECT_ID` | The API ID of the current project - a text string, e.g. ag9zfmFwaW1ldHJpY3MtcWNyEQsSBFVzZXIYgICAtILamwoM | | `PROJECT_NAME` | The name of the current project, e.g. "Project Dec 20" | | `CALL_ID` | The API ID of the current Monitor, e.g. ag9zfmFwaW1ldHJpY3MtcWNyFwsSClRlc3RTZXR1cDIYgIDgpOT1pAgM | | `CALL_NAME` | The name of the current monitor, e.g. "Create Contact" | | `CALL_RESULT_ID` | The API ID of the current API Result, e.g. ag9zfmFwaW1ldHJpY3MtcWNyGAsSC1Rlc3RSZXN1bHQzGICA4IT5pKELDA | | `CALL_AUTH_ID` | The API ID of the Auth used by the current Monitor | | `CALL_TOKEN_ID` | The API ID of the Token used by the current Monitor | | `WORKFLOW_ID` | The API ID of the current Workflow, if running in a Workflow | | `WORKFLOW_NAME` | The Name of the current Workflow | | `WORKFLOW_RESULT_ID` | The API ID of the current Workflow Result, if running in a workflow | | `CLIENT_ID` | The client id from your selected developer key set in Authentication settings | | `CLIENT_SECRET` | The client secret from your selected developer key set in Authentication settings | | `UNIXTIME` | The current time in UNIX time (i.e the number of seconds since 1970 January 1) - e.g. 335632800 | | `CREDITCARD` | Generates a random 16 digit number that passes the Luhn Checksum | | `VISACARD`\ `VISACARD`\ `MASTERCARD`\ `RANDCARD` | Generates a random number with the correct initial digits such as it appears the relevant card-type. RANDCARD is randomly picked number from of the other three | | `RANDOM` | A random integer between 1 and 10000 | | `RANDLAT`\ `RANDLNG` | A random latitude (a 6-decimal point precision number between -90.0 an 90.0) and a random longitude (a 6-decimal point precision number between -180.0 an 180.0) | | `GUID` | A RFC 4122 compliant version 4 UUID (e.g. 2dbf15b4-fa53-45c7-8e37-ea8965396b42) | | `TEST_ID` | An ID number identifying the current test (remains constant for each test), e.g.: 5872285445521408 | | `RESULT_ID` | A unique ID number identifying the specific call (changes for each call made). | | `TEST_RUN_ID` | An ID number identifying the current workflow (remains constant throughout lifetime of workflow). | | `TEST_RUN_RESULT_ID` | A unique ID number identifying the specific workflow run (remains the same for all the calls in that workflow, but is different each time that workflow is triggered). | | `USER_NAME` | Returns the 'Name' of the logged-in User. | | `USER_EMAIL` | Returns the 'Email Id' of the logged-in User | > Multiple System Variables can be combined (concatenated) to construct specific input values. For example to generate a Date & Time string in the format "**2019-05-04T14:34:45Z**", combine the `DATE` and `TIME` variables as "`DATE`T`TIME`Z". *** > **Alert variables** > > There are additional variables that are set if the Workflow has been triggered as an alert. Please see the [Alerts & Webhooks documentation for the full list](https://docs.apicontext.com/guides/alerting/using-webhooks/run-workflow.md). > **Need more advanced date or time manipulation?** > > If you require more complex date or time formatting or manipulation, create a Workflow and use our [momentjs-based REST API](https://docs.apicontext.com/guides/advanced-features/handling-variables-in-apimetrics/advanced-date-and-time-handling.md). ## Defined Variables Users can define variables as [Global Variables](https://docs.apicontext.com/concepts/environment-variables/variables-syntax.md) or as workflow variables where variables are set from returned JSON or XML. --- # Workflows > What workflows are in APIContext: multi-step monitor sequences that pass variables between steps. Source: https://docs.apicontext.com/concepts/workflows A **workflow** is an ordered sequence of monitors that run as a single unit. Each step executes in order, and you can extract values from one step's response and inject them into later steps as variables. This lets you simulate real business processes that span multiple API calls, such as creating a resource, reading it back, and then deleting it. ## Why workflows matter Individual monitors tell you whether a single endpoint is up and returning the right data. Workflows answer a harder question: **does a multi-step interaction work end to end?** Common use cases include: - **CRUD sequences**: create a record, verify it exists, update it, delete it, confirm deletion - **Authentication flows**: obtain a token, then use it to call a protected endpoint - **Data pipelines**: post data to an ingestion endpoint, then poll a downstream endpoint to confirm processing ## Key characteristics - **Variable passing**: extract values (e.g., a user ID or session token) from a step's response using JSON path or XML path, then reference them in subsequent steps - **Step-level results**: each step produces its own result with full latency breakdown, so you can pinpoint which step in the chain degraded - **Conditions per step**: each monitor in the workflow retains its own pass/fail conditions, and the workflow can be configured to stop on the first failure - **Scheduling**: workflows are scheduled exactly like individual monitors and run from the same global node network - **Scoped variables**: variables extracted within a workflow persist only for that workflow run; they do not leak into other monitors or workflows ## See also - [Creating a workflow](https://docs.apicontext.com/guides/creating-a-workflow.md): step-by-step guide to building and running workflows - [Environment variables](https://docs.apicontext.com/concepts/environment-variables.md): pre-set and global variables available in monitors and workflows - [Conditions and assertions](https://docs.apicontext.com/concepts/conditions-and-assertions.md): how pass/fail rules work at each step --- # Global and Environment Variable Syntax > Reference for global and environment variable expression syntax, fallback chains, and literal defaults. Source: https://docs.apicontext.com/concepts/environment-variables/variables-syntax The general expression for defining environment variables has the following form \{\{ var\_1 | var\_2 | workspace\_1.var\_3 | $”any alternative text” }} The environment variable expression must always be written between a pair of opening braces and a pair of closing braces. The spaces in the expression can be omitted (the expression can be written with or without spaces). For instance, the above expression can be written as \{\{var\_1|var\_2|var\_3|$”any alternative text” }}. Adding spaces increases readability, ## Syntax | Item | Description | | --- | --- | | \{\{ | Marker for the beginning of an expression | | }} | Marker for the end of an expression. | | \| | Marker separating alternatives | | var\_1 | var*1 First variable name to be searched for. Variable names can be composed of any letter from a to z and A to Z, any digit from 0 to 9 and the underscore char* | | var\_2 | Variable name to be searched for if var\_1 is not defined | | workspace\_1 | Workspace from which to retrieve var\_3 | | . | Delimiter between workspace name and variable name | | var\_3 | Variable name to be searched for, if var\_2 is not defined. | | $"any alternative text" | Alternative text if none of the variables are defined. Always the last element of the expression to be defined. Begins with: $” and end with: “ | --- # Node Locations & IP Addresses > The locations and IP addresses of every APIContext public node, so you can allowlist monitor traffic to your API in a firewall. Source: https://docs.apicontext.com/concepts/test-node-locations ## Regions and IP Address APImetrics makes monitors from our network of "nodes": these are hosted around the world in different clouds. For services behind a firewall or VPN, you can deploy [private nodes](https://apicontext.com/features/private-nodes) instead of allowlisting public IPs. For public endpoints, it may be necessary to use an IP-allowlist ("whitelisting") in your firewall so our nodes can call your API. The following tables show the IP addresses associated with each of our public nodes. > **Postman Collections** > > If you are running a Postman Collection, we use different infrastructure and our nodes **do not use** these IP addresses. NOTE: Key: * **bold** - New IP address * _italics_ - Inactive IP address * ~~strikeout~~ - Removed IP address IP Addresses MAY change in the future, we will endeavor to announce any changes to these IP addresses in advance. > **Tip** > > Running monitors from multiple cloud providers and regions enables [cross-cloud network monitoring](https://apicontext.com/features/network-monitoring), isolating whether issues originate in DNS, CDN, hosting, or the application layer. > **Save typing and protect against missing future updates** > > Each region has its own set of A records under a `<region>.agents.apimetrics.io` domain name - if possible, we recommend you use the DNS record instead of manually entering each IP address. > > If you want to allow traffic from all regions, you can use `all.agents.apimetrics.io`. ## Africa > **DNS records** > > These IP addresses are also stored as `af.agents.apimetrics.io` | Cloud | Name | Location | IP Address | | :---- | :----------------- | :------------------------- | :------------- | | AWS | Africa South 1 | Cape Town, South Africa | 13.244.215.255 | | Azure | South Africa North | Johannesburg, South Africa | 20.87.44.228 | ## Asia > **DNS records** > > These IP addresses are also stored as `as.agents.apimetrics.io` | Cloud | Name | Location | IP Address | | :-------------- | :----------------------- | :----------------------- | :----------------- | | **East** | | | | | Akamai | ap-northeast | Tokyo, Japan | 172.105.203.233 | | Akamai | jp-osa | Osaka, Japan | 172.233.72.198 | | **Akamai** | **jp-tyo-3** | **Tokyo, Japan** | **172.238.21.54** | | Akamai | ap-south | Singapore, Singapore | 172.104.173.150 | | **Akamai** | **sg-sin-2** | **Singapore, Singapore** | **172.237.91.101** | | Akamai | id-cgk | Jakarta, Indonesia | 172.232.252.122 | | AWS | Asia-Pacific East 1 | Hong Kong, Hong Kong | 18.166.32.202 | | AWS | Asia-Pacific Northeast 1 | Tokyo, Japan | 54.168.78.227 | | AWS | Asia-Pacific Northeast 2 | Seoul, Korea | 13.124.200.12 | | AWS | Asia-Pacific Northeast 3 | Osaka, Japan | 15.152.247.58 | | AWS | Asia-Pacific Southeast 1 | Singapore, Singapore | 13.250.189.72 | | AWS | Asia-Pacific Southeast 3 | Jakarta, Indonesia | 108.137.175.246 | | Azure | Asia East | Hong Kong, Hong Kong | 13.94.46.164 | | Azure | Asia Southeast 1 | Singapore, Singapore | 20.212.30.11 | | Azure | Japan East | Tokyo, Japan | 20.222.248.150 | | Azure | Japan West | Osaka, Japan | 40.74.114.210 | | Azure | Korea Central | Seoul, Korea | 20.214.191.218 | | Azure | Korea South | Busan, Korea | 52.147.120.74 | | Google | Asia East 1 | Taipei, Taiwan | 35.229.240.175 | | Google | Asia East 2 | Hong Kong, Hong Kong | 34.92.253.227 | | Google | Asia Northeast 1 | Tokyo, Japan | 104.198.83.225 | | Google | Asia Northeast 2 | Osaka, Japan | 34.97.58.150 | | Google | Asia Southeast 1 | Singapore, Singapore | 35.240.214.54 | | **Middle-East** | | | | | AWS | Middle East South 1 | Manama, Bahrain | 157.175.29.67 | | AWS | Middle East Central 1 | Dubai, UAE | 3.28.170.216 | | Azure | Qatar Central | Doha, Qatar | 20.21.99.175 | | Azure | UAE North | Dubai, UAE | 20.216.43.139 | | Google | Middle East West 1 | Tel Aviv, Israel | 34.165.140.204 | | **South** | | | | | Akamai | ap-west | Mumbai, India | 172.105.63.129 | | Akamai | in-maa | Chennai, India | 172.235.13.126 | | **Akamai** | **in-bom-2** | **Mumbai, India** | **172.236.189.20** | | AWS | Asia-Pacific South 1 | Mumbai, India | 65.1.229.47 | | Azure | India Central | Pune, India | 4.240.42.183 | | Azure | India South | Chennai, India | 52.172.33.214 | | Azure | India West | Mumbai, India | 104.211.141.29 | | Google | Asia South 1 | Mumbai, India | 35.200.211.197 | | Google | Asia South 2 | Delhi, India | 34.131.104.189 | ## Europe > **DNS records** > > These IP addresses are also stored as `eu.agents.apimetrics.io` | Name | Location | IP Address | | -------------------- | -------------------------- | ------------------- | | **de-fra-2** | **Frankfurt, Germany** | **172.238.112.208** | | es-mad | Madrid, Spain | 172.233.120.192 | | eu-central | Frankfurt, Germany | 172.104.241.248 | | eu-west | London, United Kingdom | 213.219.39.126 | | fr-par | Paris, France | 172.232.53.171 | | **gb-lon** | **London, United Kingdom** | **172.236.1.87** | | it-mil | Milan, Italy | 172.232.218.184 | | nl-ams | Amsterdam, Netherlands | 172.233.49.203 | | se-sto | Stockholm, Sweden | 172.232.134.84 | | Europe Central 1 | Frankfurt, Germany | 3.64.14.25 | | Europe West 1 | Dublin, Ireland | 54.73.43.150 | | Europe West 2 | London, United Kingdom | 35.176.183.172 | | Europe West 3 | Paris, France | 35.180.96.224 | | Europe South 1 | Milan, Italy | 15.161.195.48 | | Europe North 1 | Stockholm, Sweden | 13.49.188.184 | | Europe North | Dublin, Ireland | 52.169.146.211 | | France Central | Paris, France | 20.216.153.49 | | Europe West | Amsterdam, Netherlands | 51.124.251.198 | | Germany West Central | Frankfurt, Germany | 20.113.80.141 | | Norway East | Oslo, Norway | 20.251.8.200 | | Sweden Central | Gävle, Sweden | 20.240.63.16 | | Switzerland North | Zürich, Switzerland | 20.203.242.159 | | UK South | London, United Kingdom | 172.167.148.237 | | UK West | Cardiff, United Kingdom | 20.90.48.241 | | Europe North 1 | Hamina, Finland | 35.228.47.143 | | Europe Central 2 | Warsaw, Poland | 34.118.93.214 | | Europe Southwest 1 | Madrid, Spain | 34.175.200.47 | | Europe West 1 | St. Ghislain, Belgium | 35.189.201.203 | | Europe West 2 | London, United Kingdom | 35.230.154.98 | | Europe West 3 | Frankfurt, Germany | 35.234.98.132 | | Europe West 4 | Eemshaven, Netherlands | 35.204.190.254 | | Europe West 6 | Zurich, Switzerland | 34.65.64.120 | | Europe West 8 | Milan, Italy | 34.154.180.12 | | Europe West 9 | Paris, France | 34.155.103.180 | ## North America > **DNS records** > > These IP addresses are also stored as `na.agents.apimetrics.io` | Cloud | Name | Location | IP Address | | ------ | ------------------------- | ----------------------------------- | --------------- | | Akamai | ca-central | Toronto, ON, Canada | 192.46.223.128 | | Akamai | us-central | Richardson, TX, United States | 50.116.23.196 | | Akamai | us-east | Morris Plains, NJ, United States | 172.104.215.75 | | Akamai | us-lax | Los Angeles, CA, United States | 172.235.63.223 | | Akamai | us-mia | Miami, FL, United States | 172.235.133.207 | | Akamai | us-ord | Chicago, IL, United States | 172.234.21.53 | | Akamai | us-sea | Tukwila, WA, United States | 172.232.188.146 | | Akamai | us-southeast | Atlanta, GA, United States | 74.207.235.31 | | Akamai | us-west | Fremont, CA, United States | 192.155.85.167 | | AWS | Canada Central | Toronto, ON, Canada | 35.183.219.130 | | AWS | US East 1 | Ashburn, VA, United States | 44.198.76.94 | | AWS | US East 2 | Ashburn, VA, United States | 18.116.125.115 | | AWS | US West 1 | San Jose, CA, United States | 52.8.52.152 | | AWS | US West 2 | Boardman, OR, United States | 44.229.130.219 | | Azure | Canada Central | Toronto, ON, Canada | 4.205.47.158 | | Azure | Canada East | Montreal, QC, Canada | 20.175.42.229 | | Azure | Central US | Des Moines, IA, United States | 172.212.144.242 | | Azure | Central North US | Chicago, IL, United States | 20.102.234.19 | | Azure | Central South US | San Antonio, TX, United States | 20.97.67.47 | | Azure | East US | Washington, VA, United States | 172.173.170.159 | | Azure | East US 2 | Boydton, VA, United States | 20.10.132.93 | | Azure | West Central US | Cheyenne, WY, United States | 13.78.181.57 | | Azure | West US | San Francisco, CA, United States | 168.62.200.84 | | Azure | West US 2 | Quincy, WA, United States | 20.236.36.233 | | Azure | West US 3 | Phoenix, AZ, United States | 20.163.105.217 | | Google | North America Northeast 1 | Montreal, QC, Canada | 35.203.3.245 | | Google | North America Northeast 2 | Toronto, ON, Canada | 34.130.171.49 | | Google | US Central 1 | Council Bluffs, IA, United States | 104.155.145.40 | | Google | US East 1 | North Charleston, SC, United States | 35.237.213.134 | | Google | US East 4 | Washington, DC, United States | 35.199.44.75 | | Google | US East 4 | Columbus, OH, United States | 34.162.96.43 | | Google | US South 1 | Dallas, TX, United States | 34.174.83.131 | | Google | US West 1 | The Dalles, OR, United States | 35.230.8.220 | | Google | US West 2 | Los Angeles, CA, United States | 35.236.37.119 | | Google | US West 3 | Salt Lake City, UT, United States | 34.106.64.104 | | Google | US West 4 | Las Vegas, NV, United States | 34.125.248.12 | ## Oceania > **DNS records** > > These IP addresses are also stored as `oc.agents.apimetrics.io` | Cloud | Name | Location | IP Address | | ------- | ---------------------------- | ------------------------ | --------------- | | Akamai | ap-southeast | Sydney, Australia | 172.105.254.122 | | AWS | Asia-Pacific Southeast 2 | Sydney, Australia | 3.106.89.161 | | **AWS** | **Asia-Pacific Southeast 6** | **Aukland, New Zealand** | **3.103.9.65** | | Azure | Australia East | Sydney, Australia | 20.213.43.197 | | Azure | Australia Central | Canberra, Australia | 20.70.1.227 | | Azure | Australia Southeast | Victoria, Australia | 20.11.200.112 | | Google | Australia Southeast 1 | Sydney, Australia | 35.189.7.94 | | Google | Australia Southeast 2 | Melbourne, Australia | 34.129.12.56 | ## South America > **DNS records** > > These IP addresses are also stored as `sa.agents.apimetrics.io` | Cloud | Name | Location | IP Address | | ------ | -------------------- | ----------------- | -------------- | | Akamai | br-gru | São Paulo, Brazil | 172.233.27.237 | | AWS | South America East 1 | São Paulo, Brazil | 54.207.136.222 | | Azure | Brazil South | São Paulo, Brazil | 20.226.251.100 | | Google | South America East 1 | São Paulo, Brazil | 35.198.28.161 | | Google | South America West 1 | Santiago, Chile | 34.176.95.248 | ## China China is a separate region from Asia. The Asia region above does not include China, and neither Asia nor Worldwide includes China nodes. China monitoring nodes run API and HTTP tests from Alibaba Cloud's China regions. They are included in every plan at no additional cost and are available on request. To enable China nodes, submit a support request through the [APIContext support page](https://apicontext.com/support). ## Cloud-based DNS records If you use Clouds instead of Regions in your schedules, you can update your IP-allowlist using the following domains are available: * Akamai Cloud: `akamai.agents.apimetrics.io` * Amazon AWS: `aws.agents.apimetrics.io` * Microsoft Azure: `azure.agents.apimetrics.io` * Google Cloud: `google.agents.apimetrics.io` * Any other nodes: `other.agents.apimetrics.io` ## Changelog ### October 2026 **Added region**: China ### October 2025 **Retired IPs**: 112.109.84.70 **Added IPs**: 3.103.9.65, 172.237.91.101, 172.238.112.208, 172.238.21.54, 172.236.1.87, 172.236.189.20 ### June 2025 **Retired IPs**: 161.202.17.200, 161.202.71.142, 159.8.95.116, 159.8.184.13, 159.122.134.78, 169.54.79.53, 169.53.138.120, 158.85.82.116, 168.1.14.61 ### June 2024 **Added IPs**: 172.105.203.233, 172.104.173.150, 172.105.254.122, 172.105.63.129, 172.233.27.237, 192.46.223.128, 172.233.120.192, 172.104.241.248, 213.219.39.126, 172.232.53.171, 172.232.252.122, 172.235.13.126, 172.232.218.184, 172.233.72.198, 172.233.49.203, 172.232.134.84, 50.116.23.196, 172.104.215.75, 172.235.63.223, 172.235.133.207, 172.234.21.53, 172.232.188.146, 74.207.235.31, 192.155.85.167 ### February 2024 **Retired IPs**: 102.133.230.55, 40.83.73.26, 40.85.231.209, 104.215.148.226, 40.86.219.6, 40.115.142.32, 40.74.76.245, 52.231.67.149, 104.211.95.244, 52.231.156.73, 104.211.225.220, 104.211.155.54, 104.41.231.71, 20.216.142.144, 20.113.68.125, 51.120.92.241, 51.13.115.19, 20.240.46.233, 20.203.192.48, 51.140.8.27, 51.140.243.230, 40.113.236.215, 65.52.197.70, 104.214.49.202, 13.68.129.87, 104.210.11.191, 13.77.219.13, 104.42.37.48, 20.115.156.32, 20.25.167.160 ### January 2024 **Added IPs**: 20.213.43.197, 20.11.200.112, 20.226.251.100, 4.205.47.158, 20.175.42.229, 4.240.42.183, 172.212.144.242, 13.94.46.164, 172.173.170.159, 20.10.132.93, 20.222.248.150, 40.74.114.210, 20.214.191.218, 52.147.120.74, 20.102.234.19, 52.169.146.211, 20.87.44.228, 20.97.67.47, 20.212.30.11, 52.172.33.214, 172.167.148.237, 20.90.48.241, 51.124.251.198, 104.211.141.29, 168.62.200.84, 20.70.1.227, 20.216.153.49, 20.240.63.16, 20.203.242.159, 13.78.181.57, 20.236.36.233, 20.163.105.217, 20.113.80.141, 20.251.8.200, 20.216.43.139 ### 2022 **Added IPs**: 34.174.83.131, 34.175.200.47, 50.22.214.19, 108.137.175.246, 13.77.219.13, 15.152.247.58, 20.115.156.32, 20.203.192.48, 20.21.99.175, 20.216.142.144, 20.240.46.233, 20.25.167.160, 3.28.170.216, 34.106.64.104, 34.118.93.214, 34.125.248.12, 34.130.171.49, 34.131.104.189, 34.154.180.12, 34.155.103.180, 34.162.96.43, 34.165.140.204, 34.97.58.150, 35.236.37.119, 20.70.9.150, 34.129.12.56, 34.176.95.248 **Retired IPs**: 119.81.152.198, 169.57.18.116, 50.23.13.210, 50.23.149.234, 34.65.225.87, 35.204.32.157, 35.246.168.141, 34.89.111.234, 146.148.117.65, 35.228.43.15, 20.77.240.225, 20.108.40.238, 51.13.115.19, 20.113.86.154, 104.40.206.9, 13.70.196.208, 13.49.79.59, 15.161.200.249, 35.180.74.127, 3.8.133.66, 34.246.134.122, 18.193.95.181 ## See also - [Schedule monitors](https://docs.apicontext.com/guides/schedule-monitors.md): how to choose node locations when setting up a schedule - [Identify and allow-list APIContext monitor traffic](https://docs.apicontext.com/concepts/identifying-monitor-traffic.md): the user agent, the `traceparent` header, and a custom header you can match in a firewall rule --- # Projects and Collections > How monitors are organized into projects, and projects into collections (organizations). Source: https://docs.apicontext.com/concepts/projects-and-collections APIContext organises your monitoring work into two levels: **Projects** and **Collections**. ## Projects A **Project** is the primary unit of work. Everything you create in APIContext lives inside a project: - Monitors (API endpoints you run on a schedule) - Authentications (OAuth tokens, API keys, certificates) - Workflows (chains of monitors run in sequence) - Schedules and downtime windows - Conformance and SLO settings Projects have their own billing subscription, quota, and CASC Quality Score. ## Collections A **Collection** is a group of projects. In the current model, each user account has one Collection that holds all their projects. > **Note** > > For Enterprise accounts, a Collection maps 1:1 to an **Organization**. If you are an Enterprise customer, your admin may manage multiple users and billing across the whole Collection. The UI may show "Organization" where this documentation says "Collection": they refer to the same thing in the current tier structure. > > This page will be updated if a future tier introduces sub-Collections or independent Collection management. ## Access and roles Project membership controls who can view and edit monitors within a project. See [Access Roles](https://docs.apicontext.com/concepts/access-roles.md) for the full permission matrix. ## Creating a project See [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md) for step-by-step instructions. ## See also - [Access Roles](https://docs.apicontext.com/concepts/access-roles.md) - [Manage monitors across projects](https://docs.apicontext.com/guides/projects/moving-api-calls-between-projects.md) - [Export or import a project](https://docs.apicontext.com/guides/projects/export-or-import-an-apimetrics-project.md) --- # Identify and allow-list APIContext monitor traffic > What an APIContext API monitor sends, what a firewall or bot manager can match on, and how to add your own header so you can allow monitor traffic safely. Source: https://docs.apicontext.com/concepts/identifying-monitor-traffic A web application firewall (WAF) or bot manager can block a monitor request because it looks automated. To allow monitor traffic without opening your API to everyone, your security team needs to know what an APIContext monitor sends and which of those signals are safe to match on. This page covers API monitors. It does not cover Browser or MCP monitors. ## What an API monitor sends Three things identify a request from an API monitor: the user agent, the `traceparent` header, and the address it comes from. **User agent.** The `User-Agent` value begins with `APImetrics/`, followed by the platform version, then the `PycURL` and `libcurl` versions, then the versions of other libraries, for example `APImetrics/<version> PycURL/<version> libcurl/<version> OpenSSL/<version>`. The version numbers change as the platform is updated, so match on the `APImetrics/` prefix and never on a full string. **The `traceparent` header.** Each run sends a `traceparent` header in the [W3C Trace Context](https://www.w3.org/TR/trace-context/) format, `00-<trace-id>-<parent-id>-01`. The trace ID is 32 hexadecimal characters and the parent ID is 16, and by default both are generated at random for each run. HTTP header names are case-insensitive, so your gateway may log it as `Traceparent`. The value is recorded with the result and returned as `otel_traceparent_id` in [performance results webhooks](https://docs.apicontext.com/guides/alerting/using-webhooks/performance-results-webhook.md). Use it to find the exact request in your own server or CDN logs, as in [Akamai DataStream 2 logs](https://docs.apicontext.com/guides/integrations/third-party-logs/akamai-datastream2-ds2-logs.md). Because it is different every run, it cannot be used to allow traffic. **Source addresses.** Public nodes call your API from published IP addresses. [Node locations and IP addresses](https://docs.apicontext.com/concepts/test-node-locations.md) lists every address by region and cloud, and publishes DNS names that resolve to them, such as `all.agents.apimetrics.io` for every region. Use the DNS names where your firewall supports them, because the addresses change over time and that page keeps a changelog. ## Why the user agent alone is not enough The user agent is a plain text header that any client can send, so a rule that allows anything starting with `APImetrics/` also allows anyone who copies the string. A rule on addresses alone is stronger but is only as current as your copy of the list. For a rule that stays tight, match on a value that only your team and your monitors know, and combine it with the source addresses. ## Add your own header to a monitor An API monitor's **Advanced** tab has a **Use APIContext Standard Headers** setting, which the screen describes as "standard headers that identify APIContext calls." This page does not list those headers yet. To match on a value that you control, add your own header: a monitor can send any header you give it. Pick a header name that your own systems do not use and a long random value, add both to the monitor, and write your WAF or bot manager rule to require the header and its exact value. In the monitor editor, the header goes in the **Headers** section of the request. Through the API, it is an entry in the monitor's `headers` array, which holds `key` and `value` pairs. This request body adds one header to an API monitor with [create an API monitor](https://docs.apicontext.com/reference/api-full/create-api-monitor), and the same `headers` array is accepted by [patch an API monitor](https://docs.apicontext.com/reference/api-full/patch-api-monitor) for an existing monitor: ```json { "name": "Check payments API", "method": "GET", "url": "https://api.example.com/v1/health", "headers": [ { "key": "Accept", "value": "application/json" }, { "key": "X-Synthetic-Monitor", "value": "<long-random-value>" } ] } ``` `X-Synthetic-Monitor` is an example name chosen for this page. APIContext does not add it. The header is part of the monitor definition, so anyone who can view the monitor can read the value, and the request recorded with each result includes it. Treat it as an identifying token, not as a credential, and change it on the monitor and in your rule together if it is exposed. Each vendor documents how to build a rule that matches a request header, so follow your WAF or bot manager documentation for that side. ## Next steps - [Node locations and IP addresses](https://docs.apicontext.com/concepts/test-node-locations.md): the addresses and DNS names to allow. - [Add a monitor](https://docs.apicontext.com/guides/add-a-monitor.md): create the monitor that carries the header. - [Performance results webhook](https://docs.apicontext.com/guides/alerting/using-webhooks/performance-results-webhook.md): the payload that carries `otel_traceparent_id`. --- # Schedules > How APIContext schedules monitor runs: frequency, regions, node selection, and high-frequency monitoring. Source: https://docs.apicontext.com/concepts/schedules A **schedule** defines when and where your monitors run. Without a schedule, a monitor is just a definition that you can trigger manually. Attaching a monitor to a schedule turns it into continuous, automated observability. ## What a schedule controls Each schedule has three settings: - **Frequency**: how often each monitor runs, from once every few seconds (high-frequency tier) to once every 24 hours - **Region set**: which geographic regions or cloud providers to draw nodes from (e.g., worldwide, a specific continent, or Amazon AWS locations only). China is a separate region, available on request; neither Asia nor Worldwide includes China. See [Node locations](https://docs.apicontext.com/concepts/test-node-locations.md#china) - **Node selection mode**: **Worldwide** (APIContext automatically rotates through all nodes in the region set) or **Manual** (you pick specific node locations) When a schedule fires, APIContext selects a node from the configured region set and runs every monitor assigned to that schedule from that node. Over time, all nodes in the region set are used roughly equally, giving you geographic coverage without manual rotation. ## Frequency tiers | Interval | Availability | |----------|-------------| | 1 second to 59 seconds | Contract tier with `feature_highfreq` entitlement | | 1 minute to 24 hours | All tiers | High-frequency monitoring is designed for latency-sensitive services where sub-minute resolution matters. It consumes quota proportionally: a 5-second interval uses 12x the quota of a 1-minute interval. ## Schedules and downtimes A schedule can have **downtime windows** that pause all its monitors during planned maintenance. Organization-wide downtimes pause every schedule across the organization. See [Downtimes](https://docs.apicontext.com/concepts/downtimes.md) for details. ## Default schedule Every new project is created with a **Default Schedule** set to worldwide coverage at 5-minute intervals. You can edit or replace it at any time. ## See also - [Run a monitor on demand](https://docs.apicontext.com/guides/schedule-monitors.md): manual runs and scheduling walkthrough - [Setting and managing schedules](https://docs.apicontext.com/guides/setting-and-managing-schedules.md): detailed schedule configuration - [Test node locations](https://docs.apicontext.com/concepts/test-node-locations.md): the global node network your schedules draw from - [How usage is counted](https://docs.apicontext.com/concepts/usage-and-quota.md): what counts as one test, with a worked estimate --- # How usage is counted > What counts as one test in APIContext usage for API, workflow, browser, and MCP monitors, conformance, and retries, with a worked schedule estimate. Source: https://docs.apicontext.com/concepts/usage-and-quota APIContext measures usage in **tests**. Knowing what counts as one test lets you estimate usage before you add monitors or change a schedule, and explains why a change to frequency changes your usage. How many tests your subscription includes is on the [pricing page](https://apicontext.com/pricing/); this page explains how they are counted. ## How it works **One test is one element that the platform tests.** Each time a monitor runs from a node and its result is saved, that result counts as one test. How that works out for each kind of monitor: | What runs | Tests | |-----------|-------| | An API monitor | One test each time it runs from a node | | A workflow | One test for each step that runs. A step that does not run (for example after the workflow stops on a failure) adds nothing | | A browser monitor | One test for each step it runs | | An MCP monitor | One test for each time it runs from a node | | A retry from [Retry on failure](https://docs.apicontext.com/concepts/alerts-and-webhooks.md#retry-on-failure) | One more test for each retry | | A conformance validation | One test for each conformance element validated | ## A worked estimate Usage grows with three numbers: how many monitors (or workflow steps) a schedule runs, and how often it runs. Each time a schedule fires, it runs every monitor on it once, from one node, so each monitor stores one result per run. A day has 1,440 minutes, so a schedule that runs every 5 minutes fires 288 times a day. Put 4 API monitors on it: > 4 monitors x 288 runs a day = **1,152 tests a day**, about 34,560 in a 30-day month. Add a 3-step workflow to the same schedule, and each run adds 3 more tests: > (4 + 3) x 288 = **2,016 tests a day**. ## Where to see it Two screens show usage in the product: - **Schedules** ([open it in the platform](https://client.apimetrics.io/schedules)) lists **Est. quota usage per day** for each schedule: the number of scheduled monitors, counting each workflow step, times the runs per day. It does not include retries or runs you start yourself. - **Organization Settings** shows **Monthly Request Quota Used**: usage so far this month, predicted usage for the month, and when the count resets. See [Organizations](https://docs.apicontext.com/guides/projects/organizations.md#organization-settings). ## Next steps - [Schedules](https://docs.apicontext.com/concepts/schedules.md): how frequency and node selection work. - [Setting and managing schedules](https://docs.apicontext.com/guides/setting-and-managing-schedules.md): change how often monitors run. - [Alerts and Webhooks](https://docs.apicontext.com/concepts/alerts-and-webhooks.md#retry-on-failure): how Retry on failure works. - [Pricing](https://apicontext.com/pricing/): what each subscription includes. --- # Conformance Explained > What API conformance means in APIContext and how it relates to OpenAPI specs and security profiles. Source: https://docs.apicontext.com/concepts/conformance-explained **Conformance** in APIContext measures whether your live API traffic matches a declared contract, typically an OpenAPI Specification (OAS) or a security profile standard like FAPI or UK Open Banking. ## Types of conformance ### Schema conformance APIContext compares each monitor's response against your imported OpenAPI Specification. It checks: - **Response status codes**: is the returned status code documented in the spec? - **Response body structure**: do field names, types, and required fields match the schema? - **Headers**: are required response headers present? When a live response diverges from the spec, APIContext logs a **conformance issue** for the monitor. ### Security profile conformance APIContext also tests against named security profiles: formal standards that define required behavior for financial and regulated APIs: - **Basic Security**: HTTPS and TLS 1.2 or higher - **FAPI 2.0**: Financial-grade API profile - **FDX API 5.3**: Financial Data Exchange (No PAR with MTLS, No PAR with Private Key JWT, and PAR) - **OAuth 2.0**: the OAuth 2.0 Security Best Current Practice - **UK Open Banking**: TLS Client Auth or Private Key JWT, in the original and v4 versions - **New Zealand Open Banking** See [Security Profiles](https://docs.apicontext.com/concepts/security-profiles.md) for each one. Each profile defines a set of assertions. A monitor either passes or fails each assertion, and the aggregate result appears in your project's conformance dashboard. ### Data conformance A **data check** is a set of rules about the content of a result: how many items a list holds and what each item contains. It applies to every monitor that carries the check's tag. When a later result differs from what the rules expect, APIContext logs a **Data** conformance issue. For an MCP monitor, you create a data check from a result you trust: mark a step's result as expected, and later results of that step are checked against it. Each step of the session is checked separately. See [Set an MCP step's result as expected](https://docs.apicontext.com/guides/conformance/mcp-step-baselines.md). ## Conformance vs. monitoring Regular monitoring answers *"is my API up and fast?"* Conformance monitoring answers *"is my API behaving correctly according to its contract?"* The two complement each other: a monitor can pass its latency and availability checks while still failing conformance if the API's response body changes shape. ## Setting up conformance monitoring See [Conformance guides](https://docs.apicontext.com/guides/conformance.md) for step-by-step instructions on importing a spec, running conformance checks, and interpreting results. For an overview of conformance capabilities including drift detection and audit trails, see [API Conformance](https://apicontext.com/features/api-conformance). ## See also - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): what the Quality Score measures - [Security profiles reference](https://docs.apicontext.com/concepts/security-profiles.md): list of supported profiles with assertion details - [Set an MCP step's result as expected](https://docs.apicontext.com/guides/conformance/mcp-step-baselines.md): create a data check for an MCP monitor - [Exclude conformance monitoring](https://docs.apicontext.com/guides/conformance/exclude-conformance-monitoring.md): turn off conformance checks for one monitor --- # FAPI 2.0 > FAPI 2.0 is an API security profile based on the OAuth 2.0 Authorization Framework. APIContext checks it in checkpoints, each with multiple checks. Source: https://docs.apicontext.com/concepts/security-profiles/fapi-20 > **Note** > > FAPI conformance profiles are available on **CONTRACT tier** accounts only. Contact your account manager to enable them. See [plan availability and pricing](https://apicontext.com/pricing). **FAPI 2.0** simplifies and strengthens the high-security profile around a single, well-defined Authorization Code flow, with the newest draft updated in 2024. Use it for new financial-grade integrations that target the current FAPI baseline rather than the older Read/Write profile. ## How APImetrics checks it Our implementation of FAPI 2.0 is split into **checkpoints**, each containing multiple checks that confirm whether a particular observation is compliant. This documentation focuses on compliance using the **DPoP** (Demonstrating Proof-of-Possession) sender-constraining mechanism. APImetrics is currently working on implementing the **mTLS** sender-constraining checks for the future. Where our checks intentionally diverge from the published FAPI 2.0 guidance (for performance reasons), it is called out on the relevant checkpoint below. To turn this profile on and read its results, see the prerequisites and steps in [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md). ## Checkpoints ### Checkpoint R1: Network Layer Checks Looks at the network layer, for example your TLS certificate for the correct information and whether requests use HTTPS. (mTLS checks are planned for a future release.) ### Checkpoint R2: Authentication Token Checks Looks at your authentication tokens, such as the DPoP and Authorization headers, for the correct information. A few checks from the original FAPI 2.0 documentation are evaluated in different checkpoints in the APImetrics check rather than here. ### Checkpoint R3: DPoP Proof JWT Checks Looks at your DPoP headers and payloads to ensure the correct information is present. This checkpoint combines the original Section 8 of the FAPI 2.0 documentation, since APImetrics verifies DPoP conformance only. (mTLS checks are planned for a future release.) ### Checkpoints R4 & R5: Access Token JWT Checks Looks at the headers and payloads of your JWT access tokens to ensure the correct information is present. ### Checkpoint R6: Access Token JWT Signature Validation Looks at the headers and payloads of your JWT access tokens to ensure the correct information is present. APImetrics completes a simplified version of the original FAPI 2.0 guidelines here: we do not obtain the public keys from your application, because doing so would significantly degrade conformance-check performance. For the same reason, the final check for the JWT header and JWT payload is not performed. ### Checkpoint R8: Access Token Hash Check Looks at the access token to ensure the correct information is present. ## See also - [Security profiles overview](https://docs.apicontext.com/concepts/security-profiles.md) - [Enable a standards profile](https://docs.apicontext.com/guides/conformance/enable-a-standards-profile.md): select FAPI 2.0 and generate results - [UK Open Banking conformance](https://docs.apicontext.com/guides/conformance/uk-open-banking-conformance.md) - [Conformance guides](https://docs.apicontext.com/guides/conformance.md): set up and interpret conformance monitoring --- # Alerts and Webhooks > How APIContext alerts work: triggers, failures in a row, retries, delivery channels, and integrations with external platforms. Source: https://docs.apicontext.com/concepts/alerts-and-webhooks An **alert** is a notification that fires when a monitor produces a result matching a trigger condition. Alerts connect APIContext to your incident-response toolchain so your team learns about problems without watching a dashboard. ## Trigger conditions Each alert listens for one or more result categories: | Trigger | When it fires | |---------|---------------| | **Pass** | The monitor met all conditions (useful for negative testing: alert when a call that should fail unexpectedly succeeds) | | **Slow** | The response completed but exceeded a latency threshold | | **Warning** | The response triggered a warning condition (by default, 4xx HTTP status) | | **Error** | The response triggered an error condition (by default, 5xx HTTP status) | | **SLA** | The call or workflow step exceeded its Service Level Objective for duration or another SLA metric | You can also set a **failure threshold** on an alert, so that it fires only after several failures in a row. [How an alert decides to fire](#how-an-alert-decides-to-fire) explains how the count works. ## How an alert decides to fire Every scheduled run of a monitor produces a result, and each result has a category: Pass, Slow, Warning, Error, or SLA. An alert whose trigger matches that category fires, unless its failure threshold holds it back. Two settings decide how many results a problem produces before anyone hears about it: the failure threshold on the alert, and retries on the monitor. ### Failures in a row The failure threshold is the alert's **Only alert after this many failures in a row** field (for email alerts, **Send email after this many failures in a row**). Leave it at 0 or 1 to alert on every matching result. When it is 2 or more, APIContext counts the streak like this: - **Per monitor, across all locations.** The count follows the monitor, not the node. Results from every location the schedule uses go into the same streak, in the order they ran. - **Same category only.** The streak is the number of consecutive results with the same category as the latest one. A Pass ends the streak, and so does a result of a different category: an Error after three Warnings starts a new count at 1. - **Every day starts again.** Only results since midnight UTC count, so a problem that carries on overnight starts a new streak after midnight. - **Repeats at each multiple.** With a threshold of N, the alert fires at the Nth result in a row, then again at 2N, 3N, and so on, for as long as the streak lasts. A Pass alert is never held back by the threshold. #### Worked example A monitor runs every 5 minutes on a worldwide schedule, so each run comes from a different node. Its Error alert has a threshold of 3. | Time | Node | Result | Streak | Alert | |------|------|--------|--------|-------| | 10:00 | London | Error | 1 | No | | 10:05 | Virginia | Error | 2 | No | | 10:10 | Tokyo | Error | 3 | **Yes** | | 10:15 | Frankfurt | Error | 4 | No | | 10:20 | Sydney | Error | 5 | No | | 10:25 | London | Error | 6 | **Yes** (2 x 3) | | 10:30 | Virginia | Pass | 0 | No (the streak ends) | | 10:35 | Tokyo | Warning | 1 | No (a new streak, of Warnings) | Because the count is per monitor, a single node that fails while the others pass never builds a streak: each Pass resets it. A threshold suits failures that affect every location. To hear about one bad location, use a threshold of 1, or a schedule that runs from that location only. ### Retries before a result is recorded By default, a failed run is recorded as a failure the first time, except when a request fails at the network level, in which case the node first checks its own internet connection to ensure connectivity before reporting a failure. ### Retry on failure **Retry on failure** is an opt-in setting that runs a failed monitor again before the next scheduled run. Set it on a schedule (in the schedule's settings), on a workflow (its **Advanced** tab), or on a single monitor (its **Advanced** tab). A setting on a monitor overrides the workflow's and the schedule's, and a setting on a workflow overrides the schedule's. **Never retry** on a monitor turns retries off for that monitor even when its schedule retries. There are three methods. Each sets the wait between one retry and the next: | Method | Wait between retries | |--------|---------------------| | **Fibonacci retry** | 1, 1, 2, 3, 5, 8 seconds, and so on, so retries start 1, 2, 4, 7, 12, 20 seconds after the failed run | | **Exponential retry** | factor x base<sup>retry</sup> seconds; with a base of 2 and a factor of 1, retries start 1, 3, 7, 15 seconds after the failed run | | **Constant retry** | The same interval each time (for example 10, 20, 30 seconds after the failed run) | A result is retried when it is a Warning or an Error, other than an SLA warning or error: a run that was slow still worked, so it is not retried. Retries go on until a retry passes, until the waits add up to more than the schedule's interval (so the last retry starts before the next scheduled run), or until **Maximum retries** is reached, if you set it. Each retry produces its own result. Two options decide how retries affect the rest of the product: - **Skip notifications for retries**: the number of retries before a retry result can trigger alerts and webhooks. Without it, a failed retry alerts like any other result. - **Ignore failures in statistics**: the number of retries before a failed retry counts in the monitor's statistics. Retries and the failure threshold work together. A threshold waits for the problem to persist across scheduled runs; a retry checks again within seconds. For an API that fails briefly and recovers, Retry on failure with **Skip notifications for retries** keeps the alert quiet when the retry passes. ## Delivery channels APIContext delivers alerts to a wide range of platforms: - **Email**: simple but not recommended for high-volume scenarios - **Webhooks**: Slack, Microsoft Teams, PagerDuty, OpsGenie, VictorOps, BigPanda, Datadog, New Relic, StatusPage, and others - **OpenTelemetry**: the recommended default; sends structured telemetry to any OTLP-compatible backend (Axiom, Hydrolix, Honeycomb, etc.) Each integration type has its own configuration fields (e.g., PagerDuty requires an integration key and severity level). ## Scope: per-monitor vs. global Alerts can be configured on a single monitor or globally for every monitor in a project. Global alerts save setup time when you want the same notification rules across all endpoints. Organization-wide alert suppression is also available from Organization settings, which disables all alerts until re-enabled. ## See also - [Setting up alerts and webhooks](https://docs.apicontext.com/guides/alerting/setting-up-alerts-and-webhooks.md): step-by-step configuration guide - [Conditions and assertions](https://docs.apicontext.com/concepts/conditions-and-assertions.md): the rules that determine pass, warning, and error outcomes - [Alerting capabilities](https://apicontext.com/features/alerting): platform overview of escalation paths and team routing --- # OAuth 2.0 Security Conformance > How APImetrics evaluates OAuth 2.0 monitor sequences for conformance across authorization, token, and resource server endpoints. Source: https://docs.apicontext.com/concepts/security-profiles/oauth-2-security-conformance Ensuring that an OAuth 2.0 monitor sequence is properly formed allows critical workflows to operate reliably. We evaluate a number of specific criteria required for a valid OAuth 2.0 sequence, across various endpoints. ## Authorization endpoint We review a variety of characteristics including HTTPS scheme, TLS, query parameters, tags, and URL fragments. ## Token endpoint We review a variety of characteristics including HTTPS scheme, TLS, header, and body parameters, JWT criteria, and claims. ## Resource server endpoint We review a variety of characteristics including HTTPS scheme, TLS, header, and body parameters, token type criteria, and claims. --- # SLA Model > How APIContext measures availability, latency, and the other SLO metrics, how it decides whether an SLO is met, and what it leaves out. Source: https://docs.apicontext.com/concepts/sla-model APIContext lets you define **Service Level Objectives (SLOs)** for a project and checks your monitor results against them. This page explains how each SLO metric is measured, when an SLO counts as met, and which results are left out, so you can reproduce a number you report to a customer or a regulator. ## Definitions | Term | Meaning | |------|---------| | **SLO** | Service Level Objective: a target you set, for example "availability greater than 99.5% over a month" | | **SLA** | Service Level Agreement: a contract with a customer that formalizes one or more SLOs | | **SLI** | Service Level Indicator: the measured value an SLO is checked against | ## What an SLO is made of Each project SLO has four parts: - **Metric:** what is measured, such as Availability, Fail Rate, or Total latency. - **Comparison:** greater than (for Availability, Pass Rate, Quality score, and Apdex) or less than (for the failure rates and every latency). - **Target:** the number to beat, such as 99.5% or 500 ms. - **Period:** the time window the results are gathered over: a day, a week, or a month. The measured value is computed over every result in the period from the project's API, browser, and MCP monitors. ## How each metric is measured Every [result](https://docs.apicontext.com/concepts/results.md) is put in one category: Pass, Slow, Warning, or Fail. | Metric | How it is computed | |---|---| | **Availability** | Results that are not Fail, divided by all results. Slow and Warning results count as available | | **Pass Rate** | Pass results divided by all results | | **Slow Rate**, **Warning Rate**, **Fail Rate** | Results in that category divided by all results | | **Apdex** | Pass Rate plus half the Slow Rate | | **Latency metrics** (DNS Lookup, TCP Connect, SSL Handshake, Upload, Processing, Download, Network, Total, and the others) | The **mean** of that timing across the results in the period. It is an average, not a percentile such as p95 or p99 | | **Quality score** | The [CASC score](https://docs.apicontext.com/concepts/casc-score.md), which is calculated from results on its own terms, not from your SLO targets | ### Worked example A project's monitors return 1,000 results in a month: 970 Pass, 12 Slow, 8 Warning, and 10 Fail. - **Availability** = (1,000 − 10) / 1,000 = **99.0%** - **Pass Rate** = 970 / 1,000 = **97.0%** - **Slow Rate** = 12 / 1,000 = **1.2%** - **Apdex** = 0.970 + (0.012 / 2) = **0.976** With an SLO of "Availability greater than 99.5%", this month **does not meet** the SLO. For latency, take four results whose total times are 180, 240, 260, and 1,320 ms. The mean is 2,000 / 4 = **500 ms**. One slow result moves the mean a long way, which is why a latency SLO can fail in a month where most responses were fast. ## When an SLO counts as met The comparison is strict. "Greater than 99.5%" is met only by a value above 99.5%, and "less than 500 ms" only by a value below 500 ms. A measured value exactly equal to the target **does not** meet the SLO. In the latency example above, a mean of exactly 500 ms fails "Total latency less than 500 ms". ## What is left out - **Monitors in the not monitored list.** A monitor with **Always in not monitored list** turned on is excluded from project SLOs by default. Its results still appear on its own pages. - **Downtimes.** Monitors do not run during a [scheduled downtime](https://docs.apicontext.com/concepts/downtimes.md), so a downtime leaves no results and does not count for or against an SLO. ## Default SLOs A project starts with these SLOs, all measured over a month. Change or remove them in Conformance Settings. | Metric | Default target | |---|---| | Availability | greater than 99.5% | | Slow Rate | less than 7.5% | | DNS Lookup | less than 100 ms | | TCP Connect | less than 125 ms | | Quality score | greater than 7.99 | Projects with browser monitors also get Core Web Vitals defaults. ## Performance Change Thresholds APIContext also alerts on *relative* degradation, in addition to absolute SLO breaches. A **Performance Change Threshold** fires when: - Latency increases by more than a set number of milliseconds or a set percentage - The pass / fail grade drops by more than a set number of percentage points This catches gradual degradation that stays within the SLO but is still a meaningful trend. ## Setting up SLOs You set SLOs and Performance Change Thresholds in the **Manage Service Level Objectives and Performance Change Thresholds** section of [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings) (**Conformance**, then the **Settings** tab). See the [SLO/SLA management guide](https://docs.apicontext.com/guides/conformance/setting-up-performance-slos-slas-and-thresholds.md) for step-by-step instructions. ## See also - [SLO/SLA Management capabilities](https://apicontext.com/features/api-sla-and-slo-management): burn-rate alerting, multi-supplier attribution, and regulator-ready evidence - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): what the Quality score measures - [Results](https://docs.apicontext.com/concepts/results.md): what each monitor run records - [Setting up performance SLOs, SLAs, and thresholds](https://docs.apicontext.com/guides/conformance/setting-up-performance-slos-slas-and-thresholds.md) --- # Conditions and Assertions > How APIContext determines whether an API response is a pass, warning, or failure using configurable rules. Source: https://docs.apicontext.com/concepts/conditions-and-assertions **Conditions** and **assertions** are rules attached to a monitor that determine whether each response is classified as a pass, warning, or failure. Without conditions, APIContext uses sensible defaults (2xx = pass, 4xx = warning, 5xx = error). With conditions, you define exactly what "correct" means for each endpoint. You set a monitor's conditions in the **Assertions** section of its **Edit** tab (open it from [Monitors](https://client.apimetrics.io/tests/)). Conditions for the whole project are under **Project Conditions: HTTP**, **Header**, and **Latency** in the sidebar. ## Conditions vs. assertions The terms are used interchangeably in parts of the UI, but they serve slightly different roles: - **Conditions** control flow: they decide what happens after a call completes, such as whether a workflow should stop on failure (for example, only run the next step if the previous response was successful) - **Assertions** verify data: they check that specific parts of the response match expected values (like the status code, headers, or even the full response body) In practice, both are configured in the same place and both contribute to the pass/fail/warning verdict. ## What you can check | Check type | Example | |------------|---------| | **HTTP status code** | Expect 200; treat 500 as a pass for negative testing | | **Response header** | `Content-Type` must equal `application/json` | | **Response body (string)** | Body must contain the word `"success"` | | **JSON path** | `user.id` must equal `5` | | **Raw response (`_raw`)** | Full response body must match an exact string or contain a substring | | **Response size (bytes)** | Response must be less than 100 bytes, or exactly 0 for empty-body checks | | **Latency** | Total latency over 1000 ms triggers a "passed but slow" result | ## How conditions affect other features - **Alerts** fire based on the verdict that conditions produce: a warning condition triggers warning alerts, an error condition triggers error alerts - **CASC Quality Score** uses the pass/fail ratio driven by conditions as its primary input - **Workflows** can stop at the first failing step, which is determined by that step's conditions ## See also - [Setting assertions and conditions](https://docs.apicontext.com/guides/set-conditions.md): how to configure conditions in the UI - [Alerts and webhooks](https://docs.apicontext.com/concepts/alerts-and-webhooks.md): what happens when a condition triggers a non-pass verdict - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): how pass/fail rates flow into the quality score --- # Access Roles > The five project roles in APIContext and what each one can do. Roles are assigned per project, so a user can hold different roles on different projects. Source: https://docs.apicontext.com/concepts/access-roles APIContext uses five project-level roles to control what members can see and change. Roles are assigned per-project: a user can be an EDITOR on one project and a VIEWER on another. ## Role capabilities | Capability | OWNER | MANAGER | EDITOR | ANALYST | VIEWER | |---|:---:|:---:|:---:|:---:|:---:| | View monitors and results | ✓ | ✓ | ✓ | ✓ | ✓ | | Run monitors on demand | ✓ | ✓ | ✓ | ✓ | | | Create / edit monitors | ✓ | ✓ | ✓ | | | | Configure Monitor Authentication | ✓ | ✓ | ✓ | | | | Configure alerts and webhooks | ✓ | ✓ | ✓ | | | | Manage schedules | ✓ | ✓ | ✓ | | | | Manage project settings | ✓ | ✓ | | | | | Invite / remove project members | ✓ | ✓ | | | | | Transfer project ownership | ✓ | | | | | | Delete the project | ✓ | | | | | ## Role descriptions **OWNER**: Full control. There is always exactly one OWNER per project; ownership can be transferred to another member. **MANAGER**: Can do everything an EDITOR can do, plus manage project settings and membership. Cannot delete the project or transfer ownership. **EDITOR**: The standard operational role. Creates and edits monitors, manages authentications, configures alerts. **Monitor Authentication setup requires at least EDITOR.** **ANALYST**: Read + run access. Can trigger on-demand monitor runs and access all results and analytics, but cannot create or modify monitors. **VIEWER**: Read-only access. Can view monitors, results, and dashboards, but cannot trigger runs or modify anything. ## Monitor Authentication and roles Configuring **Monitor Authentication** (OAuth tokens, API keys, signing certificates) requires **EDITOR or higher**. This ensures that credentials are only added or modified by users with write access to the monitors that use them. ## Inviting a user to a project See [Invite a user to join a project](https://docs.apicontext.com/guides/projects/invite-a-user-to-join-a-project.md) for step-by-step instructions. ## See also - [Projects and Collections](https://docs.apicontext.com/concepts/projects-and-collections.md) - [Authentication settings guide](https://docs.apicontext.com/guides/authentication-settings.md) --- # Basic Security Conformance Checks > The Basic Security Conformance profile checks the essentials, such as HTTPS and the TLS version, for each monitor as a baseline for API security. Source: https://docs.apicontext.com/concepts/security-profiles/basic-security-conformance-profile APImetrics include a standard definition for baseline security validation on all monitors. Our Basic Security Conformance profile lays the groundwork for a secure API by confirming the essentials, like HTTPS and TLS version, to uphold data integrity and confidentiality. It's a great place to start your API posture journey. # Basic Security This Security Profile performs two checks for each monitor: Is it using HTTPS? Is it using TLS version 1.2 or higher? To use this profile, select it in the **Manage Standards Profiles** section of [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings). ## See also - [API Security monitoring](https://apicontext.com/features/api-security): runtime security validation beyond design-time checks, with audit evidence for compliance teams --- # Results > What APIContext result data contains: latency breakdown, HTTP status, pass/fail verdict, and response details. Source: https://docs.apicontext.com/concepts/results Every time a monitor runs, APIContext records a **result**: a complete snapshot of the request, the response, and the verdict. Results are the raw data that powers dashboards, quality scores, and conformance analysis. ## What a result contains Each result stores: | Field | Description | |-------|-------------| | **Pass/Fail/Warning verdict** | Determined by the monitor's conditions and assertions | | **HTTP status code** | The status code returned by the API | | **Latency breakdown** | DNS lookup, TCP connect, TLS handshake, server processing time, data transfer, and total time | | **Trigger reason** | Why the call was made: manual run, scheduled event, or another trigger | | **Node location** | Which global test node executed the call | | **Request sent** | The full HTTP request including method, URL, headers, and body | | **Response received** | The full HTTP response including headers and body | | **Variables** | Any environment or workflow variables that were set during the call | For results from [China nodes](https://docs.apicontext.com/concepts/test-node-locations.md#china), a response payload above 2,000 bytes may not be stored, so it may not be available for evaluation by expected-result conditions. ## Where to find results Results appear in three places: - **Monitor Results tab**: every execution of a single monitor, with drill-down to full request/response detail - **All Call Results** (under Investigate): a project-wide view of every request across all monitors, filterable by result category, location, and time range - **Project Overview**: an aggregated summary row per monitor showing Quality Score, availability percentage, slow percentage, and average latency ## Why the latency breakdown matters The breakdown into DNS, TCP, TLS, processing, and transfer segments lets you isolate whether a performance problem originates at the network layer, the CDN, or the application itself. This feeds into APIContext's network monitoring capabilities. ## See also - [Understanding the results](https://docs.apicontext.com/guides/view-results.md): how to navigate and interpret the results UI - [CASC Score](https://docs.apicontext.com/concepts/casc-score.md): how results feed into the quality score - [Network monitoring](https://apicontext.com/features/network-monitoring): using latency breakdowns to diagnose network-layer issues --- # Authentication Model > How APIContext manages credentials for monitors: authentication setups, tokens, and supported flows. Source: https://docs.apicontext.com/concepts/authentication-model APIContext separates **credential configuration** from **runtime tokens** so that monitors can authenticate against protected APIs without embedding secrets in individual call definitions. ## Authentication setups An **authentication setup** is a reusable credential configuration attached to a project. It defines how APIContext obtains an access token: the grant type, endpoints, client credentials, scopes, and any extra parameters. You create one setup and reference it from any number of monitors in the same project. ## Tokens A **token** is the runtime credential that APIContext uses when executing a monitor. For OAuth flows, the platform handles the full token lifecycle: it exchanges the setup's credentials for an access token and caches it. It refreshes the token automatically when the token has a refresh token or uses the Client Credentials grant; otherwise a person signs in again. For simpler schemes (API key, Basic Auth), the token is the static credential itself. ## Supported flows | Flow | When to use | |------|-------------| | **API Key** | Static key passed as a header or query parameter | | **Basic Auth** | Username/password encoded in the `Authorization` header | | **OAuth 2.0: Client Credentials** | Server-to-server; no user context | | **OAuth 2.0: Authorization Code** | User-delegated access; requires one-time browser consent | | **OAuth 2.0 + JWS/JWT** | Signed assertions (e.g., Google service accounts) | | **OAuth 1.0a** | Legacy APIs that require signed requests | | **Mutual TLS (mTLS)** | Client certificate authentication | | **Custom** | Arbitrary token-fetch logic via chained API calls | ## Sharing restrictions Authentication setups are scoped to a single project. Tokens cannot be shared across projects: this prevents accidental credential leakage when monitors are copied or moved. ## See also - [Authentication settings guide](https://docs.apicontext.com/guides/authentication-settings.md): creating and configuring authentication setups - [OAuth fundamentals](https://docs.apicontext.com/guides/authentication-settings/fundamentals-of-oauth.md): detailed OAuth 2.0 walkthrough - [Device code auth](https://docs.apicontext.com/guides/device-code-auth.md): authenticating from headless environments --- # Downtimes > Scheduled maintenance windows that pause monitoring to avoid false alerts. Source: https://docs.apicontext.com/concepts/downtimes A **downtime** is a scheduled window during which APIContext pauses monitoring and suppresses alerts. Use downtimes to prevent false positives during planned maintenance, deployments, or known outage windows. ## Two scopes | Scope | What it pauses | Who can set it | |-------|----------------|----------------| | **Schedule-level** | A single monitor's schedule in a specific project | Project Editors and above | | **Organization-level** | All monitors across every project in the organization | Organization Admins | Schedule-level downtimes are the most common: they let you silence a specific monitor while its target API is under maintenance. Organization-level downtimes are for broader events like infrastructure-wide maintenance windows. ## How downtimes affect data During a downtime window: - **Monitors do not run**: no API calls are made, so there are no results to record - **Alerts are suppressed**: even if a monitor was already in a failure state, no new alerts fire - **Quality scores are unaffected**: the paused period is excluded from CASC score calculations, so a planned outage does not lower your score When the downtime ends, monitoring resumes automatically on the next scheduled interval. ## See also - [Managing downtimes guide](https://docs.apicontext.com/guides/projects/downtimes.md): creating and editing schedule-level downtimes - [Schedules concept](https://docs.apicontext.com/concepts/schedules.md): how monitoring frequency and regions work - [Alerts and Webhooks concept](https://docs.apicontext.com/concepts/alerts-and-webhooks.md): how alert suppression interacts with downtimes --- # Project basics and access levels > What a project is, how projects appear in your account, and the five access levels a user can hold on a project. Source: https://docs.apicontext.com/concepts/project-basics-and-access-levels ## Project basics APIs are kept in projects in your personal collection. ## Project access levels A project has five access levels: Owner, Manager, Editor, Analyst, and Viewer. Each user holds one level per project, so the same person can be an Editor on one project and a Viewer on another. Every project has an Owner. For what each level can do, see [Access Roles](https://docs.apicontext.com/concepts/access-roles.md). Owners and Managers set a user's level in [Settings > Project](https://client.apimetrics.io/settings/project), under **Project Administrator Settings**. ## Next steps - [Projects](https://docs.apicontext.com/guides/projects.md): invite users, create a project, and delete a project. - [Create a new project](https://docs.apicontext.com/guides/projects/create-a-new-project.md): the ways to create a project. - [Projects and Collections](https://docs.apicontext.com/concepts/projects-and-collections.md): how monitors are organized into projects and collections. - [Access Roles](https://docs.apicontext.com/concepts/access-roles.md): the project roles and their permissions. --- # Security Profiles > The API security conformance standards that APIContext checks, with a link to each profile, so you can see whether your APIs conform to them. Source: https://docs.apicontext.com/concepts/security-profiles APIContext's [API security monitoring](https://apicontext.com/features/api-security) validates runtime security behavior against production APIs, not just design-time checks. Below are the conformance standards that APImetrics checks: * [Basic Security](https://docs.apicontext.com/concepts/security-profiles/basic-security-conformance-profile.md) * [FAPI 2.0](https://docs.apicontext.com/concepts/security-profiles/fapi-20.md) * [FDX API 5.3](https://docs.apicontext.com/concepts/security-profiles/fdx-api-53.md), in three variants: * FDX API 5.3 (No PAR, MTLS) and FDX API 5.3 (No PAR, Private Key JWT): see [No PAR](https://docs.apicontext.com/concepts/security-profiles/fdx-api-53.md#no-par) * FDX API 5.3 (PAR): see [PAR](https://docs.apicontext.com/concepts/security-profiles/fdx-api-53.md#par) * OAuth 2.0: based on the OAuth 2.0 Security Best Current Practice, which sets security requirements for OAuth 2.0 clients and servers * [UK Open Banking](https://docs.apicontext.com/guides/conformance/uk-open-banking-conformance.md), in four variants: UK Open Banking (TLS Client Auth), UK Open Banking (Private Key JWT), UK Open Banking v4 (TLS Client Auth), and UK Open Banking v4 (Private Key JWT) * New Zealand Open Banking You choose a project's profile in the **Manage Standards Profiles** section of [Conformance Settings](https://client.apimetrics.io/governance/conformance/settings) (**Conformance**, then the **Settings** tab). ## See also - [Conformance guides](https://docs.apicontext.com/guides/conformance.md): how to set up and interpret conformance monitoring --- # Variables > Links to guidance on creating and using environment variables in monitors and on building workflows that pass data between steps. Source: https://docs.apicontext.com/concepts/environment-variables ## See also - [Environment variables guide](https://docs.apicontext.com/guides/environment-variables.md): how to create and use environment variables in your monitors - [Creating a workflow](https://docs.apicontext.com/guides/creating-a-workflow.md): workflows make heavy use of environment variables to pass data between steps --- # APIContext CLI > Configuration, endpoints, built-in commands, and global flags for the apimetrics CLI, which manages monitors, projects, workflows, and schedules. Source: https://docs.apicontext.com/cli The [APIContext CLI](https://apicontext.com/features/cli) (`apimetrics`) lets you manage API monitors, projects, workflows, schedules, and more without opening a browser. The command set is generated at runtime from the APIContext OpenAPI description, so it varies by endpoint, API-description version, and account tier. A small set of [built-in commands](#built-in-commands) is always present. See [Generated commands](https://docs.apicontext.com/cli/generated-commands.md) for the full explanation and how to discover what is available to you. To install the CLI, sign in, select a project, and run your first command, follow [Install and set up the CLI](https://docs.apicontext.com/guides/install-and-set-up-the-cli.md). ## Configuration and endpoints The CLI stores its state in a per-user config directory provided by the OS: | Platform | Default config dir | |---|---| | macOS | `~/Library/Application Support/apimetrics` | | Linux | `~/.config/apimetrics` | Override it with the `APIMETRICS_CONFIG_DIR` environment variable. The active project is recorded in `state.json` inside that directory. A separate cache directory holds the cached OpenAPI description and tokens; override it with `APIMETRICS_CACHE_DIR`. The endpoint the CLI talks to (and where it discovers the OpenAPI description) is compiled into the binary. You can override the server for a single invocation with the global `-s/--rsh-server` flag. ## Built-in commands These commands are always available, regardless of the loaded API description: | Command | What it does | |---|---| | `apimetrics login` / `logout` | Authenticate / clear credentials. See [Authentication](https://docs.apicontext.com/cli/reference/authentication.md) | | `apimetrics completion <shell>` | Generate a shell completion script (see [Shell completion](https://docs.apicontext.com/cli/reference/global-flags.md#shell-completion)) | | `apimetrics project select` / `show` | Manage the active project. See [Project](https://docs.apicontext.com/cli/reference/project.md) | | `apimetrics bulk …` | Client-side bulk sync of resources. See [Bulk](https://docs.apicontext.com/cli/reference/bulk.md) | | `apimetrics skills install` / `onboard` | Set up AI coding agents with APIContext workflows. See [Skills & onboard](https://docs.apicontext.com/cli/reference/skills.md) | ## Output and global flags Every command accepts the `--rsh-*` [global flags](https://docs.apicontext.com/cli/reference/global-flags.md). The most important one to know: ```bash # Get machine-readable JSON — note it is -o json, NOT --json apimetrics list-monitors -o json ``` ## Command reference - [CLI Command Reference](https://docs.apicontext.com/cli/reference.md): built-in command groups and global flags - [Generated commands](https://docs.apicontext.com/cli/generated-commands.md): how runtime OpenAPI commands work and how to discover them ## What's next? - [Configuration as code](https://apicontext.com/features/configuration-as-code): define monitoring in YAML/JSON, version-control in Git, deploy through CI/CD - [Monitor your first API](https://docs.apicontext.com/monitor-your-first-api.md): end-to-end UI tutorial - [API Reference](https://docs.apicontext.com/reference/intro.md): full REST API reference --- # CLI Command Reference > Reference for the apimetrics CLI: built-in command groups, global flags, and how generated commands work. Source: https://docs.apicontext.com/cli/reference The `apimetrics` CLI has two kinds of commands: - **Built-in commands**: hand-authored commands that are always present, even before any API description is loaded. They are documented on the pages below. - **Generated commands**: one command per API operation, created at runtime from the loaded OpenAPI description (for example `list-monitors`, `create-api-monitor`). These vary by endpoint, API-description version, and account tier, so they are not enumerated here. See [Generated commands](https://docs.apicontext.com/cli/generated-commands.md) for how they work and how to discover them. Every command accepts the [global flags](https://docs.apicontext.com/cli/reference/global-flags.md) (the `--rsh-*` family). ## Built-in command groups | Group | Commands | |---|---| | [Authentication](https://docs.apicontext.com/cli/reference/authentication.md) | `login`, `logout` (OAuth 2.0 auth-code + PKCE, service accounts, named profiles) | | [Project](https://docs.apicontext.com/cli/reference/project.md) | `project select`, `project show` | | [Bulk](https://docs.apicontext.com/cli/reference/bulk.md) | `bulk init`, `list`, `pull`, `status`, `diff`, `reset`, `push` | | [Skills & onboard](https://docs.apicontext.com/cli/reference/skills.md) | `skills install`, `onboard` | | [Global flags](https://docs.apicontext.com/cli/reference/global-flags.md) | The `--rsh-*` flags and output controls (`-o json`, not `--json`) | ## See also - [Install and set up the CLI](https://docs.apicontext.com/guides/install-and-set-up-the-cli.md): installation, authentication, first monitor - [CLI overview](https://docs.apicontext.com/cli.md): configuration, endpoints, built-in commands - [Generated commands](https://docs.apicontext.com/cli/generated-commands.md): runtime OpenAPI command generation --- # Generated commands > How the apimetrics CLI turns the APIContext OpenAPI description into commands at runtime, and how to discover what is available. Source: https://docs.apicontext.com/cli/generated-commands Most of what you can do with the `apimetrics` CLI is not hard-coded into the binary. At startup, the CLI loads the APIContext **OpenAPI description** from its configured server and turns **each API operation into its own CLI command**. That is why you can run commands like: ```bash apimetrics list-monitors apimetrics create-api-monitor name: "Check payments API", method: GET, url: https://api.example.com/v1/health apimetrics get-result <result-id> ``` even though none of those are written into the binary's source. Each one corresponds to an operation in the OpenAPI description. ## How generation works 1. On startup the CLI fetches (and caches) the OpenAPI description from the configured endpoint. 2. For every operation in that description, it registers a command, deriving the command name, flags, and input and response schemas from the operation. 3. Those generated commands sit alongside the always-present [built-in commands](https://docs.apicontext.com/cli/reference.md) (`login`, `project select`, `bulk`). The description is cached locally (in the cache directory described in the [CLI overview](https://docs.apicontext.com/cli.md)), so subsequent runs are fast. ## Auto-authentication Generated commands talk to the live API, so they need credentials. You do not have to log in first. When a command needs authentication and none is cached, the CLI **automatically starts the [login flow](https://docs.apicontext.com/cli/reference/authentication.md)** (OAuth 2.0 authorization-code + PKCE by default). After that it remembers your credentials and active project. ## The command set varies Because the commands come from the loaded OpenAPI description, **the available set is not fixed**. It depends on: - the **configured endpoint** the CLI points at, - the **version** of the API description served there, and - your **account tier / role**, which can gate which operations are exposed. A list of commands copied from these docs, a script, or another machine is therefore a snapshot of one moment. It is not a permanent contract. ## Discovering what is available For your setup, the binary is the only authoritative list. Use `--help`: ```bash # List every command available to you, grouped by category apimetrics --help # Inspect a single generated command: its flags and request/response schema apimetrics list-monitors --help ``` Combine with the [global flags](https://docs.apicontext.com/cli/reference/global-flags.md), for example `-o json` for machine-readable output: ```bash apimetrics list-monitors -o json ``` ## See also - [Install and set up the CLI](https://docs.apicontext.com/guides/install-and-set-up-the-cli.md): install, authenticate, select a project - [CLI overview](https://docs.apicontext.com/cli.md): configuration, endpoints, built-in commands - [CLI Command Reference](https://docs.apicontext.com/cli/reference.md): the always-present built-in commands - [API Reference](https://docs.apicontext.com/reference/intro.md): the full REST API the generated commands map onto - [Projects and collections](https://docs.apicontext.com/concepts/projects-and-collections.md): the project context generated commands operate in --- # Project > The project commands in the apimetrics CLI select and show the active project. Most generated commands run against the active project, so set it once. Source: https://docs.apicontext.com/cli/reference/project Manage the active project. Most generated commands operate against the active project, so set it once and the CLI remembers it (stored in `state.json` in your [config directory](https://docs.apicontext.com/cli.md)). ``` apimetrics project [command] ``` ## `project select` Set the active project for all subsequent commands. ``` apimetrics project select [project-id] ``` Provide a project ID directly to set it without prompting, or omit it to choose interactively from the list of projects you have access to. ```bash # Choose interactively apimetrics project select # Set directly by ID (no prompt) apimetrics project select prj_abc123 ``` ## `project show` Show the active project. ``` apimetrics project show [--id] ``` | Flag | Description | |---|---| | `--id` | Print the project ID instead of the name | ```bash # Print the active project name apimetrics project show # Print just the ID (useful in scripts) apimetrics project show --id ``` ## See also - [Authentication](https://docs.apicontext.com/cli/reference/authentication.md): sign in before selecting a project - [Global flags](https://docs.apicontext.com/cli/reference/global-flags.md) --- # Authentication > apimetrics CLI authentication: login, logout, service accounts, OAuth 2.0 flows, and named profiles. Source: https://docs.apicontext.com/cli/reference/authentication The `apimetrics` CLI authenticates with OAuth 2.0. There is **no API key** environment variable and **no `api configure` command**: sign in with `login`. Most commands auto-trigger login when they need credentials, so running `login` explicitly is rarely required. ## `login` Log in to APImetrics. The default interactive flow uses the **OAuth 2.0 authorization-code flow with PKCE** (`code_challenge_method=S256`) and opens your browser to complete sign-in. ``` apimetrics login ``` ```bash # Sign in interactively (browser-based, auth-code + PKCE) apimetrics login ``` ### `login --device` Use the `--device` flag to sign in by confirming a short code in a browser on any device, instead of being redirected back to the machine running the CLI. This is the right choice over SSH, in a container, or anywhere the browser cannot reach `localhost`. ```bash apimetrics login --device ``` The CLI prints a code and a verification address. Open the address in a browser on any device, confirm the code, and the CLI finishes signing in. For the underlying protocol, see [Device Code Authorization flow](https://docs.apicontext.com/guides/device-code-auth.md). ### How long a login lasts A browser or device-code login stays valid while you use it: when the access token expires, the CLI renews it in the background without opening the browser. Run `apimetrics login` again after 3 days without using the CLI, or 7 days after you signed in, whichever comes first. Commands that need credentials start the login for you. ## `logout` Remove the cached login credentials and the active project, forcing re-authentication on the next request. ``` apimetrics logout ``` ```bash apimetrics logout ``` ## Service accounts A **service account** authenticates without a browser, which makes the CLI usable from CI, cron jobs, and other headless environments. Create one in your organization's settings (see [Organizations](https://docs.apicontext.com/guides/projects/organizations.md#service-accounts)) and download the JSON file it gives you: ```json { "name": "ci-runner", "client_id": "...", "client_secret": "...", "audience": "https://client.apimetrics.io" } ``` Point the CLI at that file with `--service-account`. Every request then authenticates with the OAuth 2.0 client-credentials grant instead of the cached browser login: ```bash apimetrics list-monitors --service-account ./ci-runner.apimetrics.json ``` You can also set the file path in an environment variable, which is the preferred approach in CI: ```bash export APIMETRICS_SERVICE_ACCOUNT=/secrets/ci-runner.apimetrics.json apimetrics list-monitors ``` > **Danger** > > The file holds a live secret. Keep it out of version control. ### Choosing a project Service accounts are granted access to specific projects, and headless runs cannot answer an interactive project prompt. Name the project for the run with `--project-id`, or set `APIMETRICS_PROJECT_ID`: ```bash apimetrics list-monitors \ --service-account /secrets/ci-runner.apimetrics.json \ --project-id <project-id> ``` `--project-id` applies to that run only and never overwrites the project saved by `project select`. To see which projects a service account can reach, run `apimetrics project select --service-account <file>` from a terminal. ### Service account behavior - Access tokens last an hour and are cached per set of credentials. A service account never uses your interactive login's token, or another service account's. Rotating the secret invalidates the cache. - The client-credentials grant issues no refresh token, so when the access token expires the CLI requests a new one. - `apimetrics login --service-account <file>` fetches a token without making an API call, which is a quick way to check that credentials work. - `apimetrics logout --service-account <file>` drops that account's cached token and leaves your browser login and selected project alone. ## OAuth 2.0 flows The CLI supports three OAuth 2.0 flows: | Flow | When to use | |---|---| | **Authorization code + PKCE** (`S256`) | Default for interactive/human login. Opens a browser. | | **Device code** | Interactive login when the browser is on another device, such as over SSH. Use `login --device`. | | **Client credentials** | Machine-to-machine / unattended automation (CI, agents) with no browser. Used by [service accounts](#service-accounts). | The interactive `login` command uses authorization-code + PKCE against the binary's configured authorization server. For client-credentials, use a [service account](#service-accounts). ## Named profiles Use the global `-p`/`--rsh-profile` flag to keep separate credential sets (for example, interactive vs. machine-to-machine, or staging vs. production). The default profile is named `default`. ```bash # Use a profile named "ci" (e.g. configured for client-credentials) apimetrics list-monitors -p ci -o json ``` See [Global flags](https://docs.apicontext.com/cli/reference/global-flags.md) for the full `--rsh-*` flag list. ## See also - [Project](https://docs.apicontext.com/cli/reference/project.md): select a project after signing in - [Organizations](https://docs.apicontext.com/guides/projects/organizations.md#service-accounts): create service accounts - [Authentication model](https://docs.apicontext.com/concepts/authentication-model.md) - [CLI overview](https://docs.apicontext.com/cli.md): config directory and endpoints --- # Bulk > apimetrics CLI bulk commands: client-side bulk resource management (init, list, pull, status, diff, reset, push). Source: https://docs.apicontext.com/cli/reference/bulk Client-side bulk resource management. The `bulk` group lets you check out a set of resources locally, edit them as files, and sync changes back to the server: a Git-like workflow for API resources. This is part of APIContext's [configuration as code](https://apicontext.com/features/configuration-as-code) approach to monitoring management. > **Note** > > The `bulk` group is **hidden** from the root `--help` listing, but it is fully available. Run `apimetrics bulk --help` to see it. ``` apimetrics bulk [command] ``` Each subcommand has a short alias (shown below). Several accept `-m`/`--match` to operate on a subset of files using a match expression. ## `bulk init` (alias `i`) Initialize a new bulk checkout from a URL that returns a list of resources (each with a link and a version). Use `-f`/`--rsh-filter` to reshape the response and `--url-template` to build links from item IDs when no link is present. ``` apimetrics bulk init URL [-f filter] [--url-template tmpl] ``` | Flag | Description | |---|---| | `--url-template string` | URL template to build links (e.g. from item IDs) | ```bash apimetrics bulk init api.example.com/users -f 'body.{url, version: last_login}' apimetrics bulk init api.example.com/users -f 'body.{id, version: last_login}' --url-template='/users/{id}' ``` ## `bulk list` (alias `ls`) List checked-out files. ``` apimetrics bulk list [--match expr] [-f filter] ``` | Flag | Description | |---|---| | `-m, --match string` | Expression to match | ```bash apimetrics bulk list -m 'id contains abc' apimetrics bulk list -m 'reviews where rating > 4' ``` ## `bulk pull` (alias `pl`) Pull remote updates. Does not overwrite local changes. ```bash apimetrics bulk pull ``` ## `bulk status` (alias `st`) Show the local and remote added/changed/removed files. ```bash apimetrics bulk status ``` ## `bulk diff` (alias `di`) Show a diff of local or remote changed files. ``` apimetrics bulk diff [file... | --match expr | --remote] ``` | Flag | Description | |---|---| | `-m, --match string` | Expression to match | | `--remote` | Show remote diffs instead of local | ```bash apimetrics bulk diff apimetrics bulk diff --remote ``` ## `bulk reset` (alias `re`) Undo local changes to files. ``` apimetrics bulk reset [file... | --match expr] ``` | Flag | Description | |---|---| | `-m, --match string` | Expression to match | ```bash apimetrics bulk reset -m 'id contains abc' ``` ## `bulk push` (alias `ps`) Upload local changes to the remote server. ```bash apimetrics bulk push ``` ## See also - [Global flags](https://docs.apicontext.com/cli/reference/global-flags.md): `-f/--rsh-filter` and the rest of the `--rsh-*` family - [CLI overview](https://docs.apicontext.com/cli.md) --- # Skills & onboard > apimetrics CLI agent integration: skills install and the onboard command. Source: https://docs.apicontext.com/cli/reference/skills These commands help you wire APIContext workflows into an AI coding agent. ## `skills install` Install APIContext skills into an agent skills directory. Specify exactly one target. ``` apimetrics skills install [--claude-skills | --claude-code | --codex | -d dir] ``` | Flag | Description | |---|---| | `--claude-skills` | Install eight operational [Claude Code Skills](#claude-code-skills) into `.claude/skills/<name>/SKILL.md` | | `--claude-code` | Install the setup skills into `.claude/commands/` as slash commands and write `.claude/agents.md` | | `--codex` | Install into `.codex/skills/` | | `-d, --dir string` | Install into a custom directory path | ```bash # Install the operational Claude Code Skills apimetrics skills install --claude-skills # Install as Claude Code slash commands (+ .claude/agents.md) apimetrics skills install --claude-code # Install as Codex skills apimetrics skills install --codex # Install into a custom directory apimetrics skills install --dir ./custom ``` ### Claude Code Skills `--claude-skills` installs these workflows, one directory per skill: | Skill | Use it to | |---|---| | `apimetrics-project-bootstrap` | Set up monitoring for a new service | | `apimetrics-weekly-health-review` | Produce a reliability report for the last seven days | | `apimetrics-failure-investigation` | Find the root cause of a failing result or series of results | | `apimetrics-incident-triage` | Assess blast radius and common cause across many monitors | | `apimetrics-monitoring-estate-audit` | Review coverage and hygiene across your monitors | | `apimetrics-slo-review` | Review SLO design and attainment | | `apimetrics-config-as-code` | Make reviewed bulk edits with a rollback path (see [Bulk](https://docs.apicontext.com/cli/reference/bulk.md)) | | `apimetrics-performance-analytics` | Analyze latency percentiles, component timing, and DNS drift | > **Caution** > > The `project-bootstrap` and `config-as-code` skills change your configuration. They are designed to require explicit intent, a snapshot before the change, and a stated rollback path. ### Other agents The same workflows are described in an `AGENTS.md` file in the CLI repository, which tools such as OpenAI Codex, Cursor, and Gemini CLI read. ## `onboard` Print all embedded APIContext skill workflows to stdout. Run it and include the output in your agent's context to onboard it on the correct CLI workflows. Note: `onboard` is a **top-level** command (`apimetrics onboard`), not a subcommand of `skills`. ``` apimetrics onboard ``` ```bash # Pipe the embedded workflows into your agent's context apimetrics onboard > apimetrics-skills.md ``` ## See also - [CLI overview](https://docs.apicontext.com/cli.md) - [Authentication](https://docs.apicontext.com/cli/reference/authentication.md): use a service account for unattended agents - [Global flags](https://docs.apicontext.com/cli/reference/global-flags.md) --- # Global flags > apimetrics CLI global flags, including the --rsh-* family, JSON output, and output controls. Source: https://docs.apicontext.com/cli/reference/global-flags The `apimetrics` CLI global flags use the `--rsh-*` family. They apply to **every** command, whether built in or generated. | Flag | Description | |---|---| | `-o, --rsh-output-format string` | Output format: `auto`, `json`, `table`, … (default `auto`) | | `-f, --rsh-filter string` | Filter / project results using a shorthand query | | `-H, --rsh-header stringArray` | Add a custom header | | `-q, --rsh-query stringArray` | Add a custom query parameter | | `-p, --rsh-profile string` | API auth profile (default `default`) | | `-s, --rsh-server string` | Override `scheme://server:port` for an API | | `-r, --rsh-raw` | Output the query result raw rather than escaped | | `--rsh-no-paginate` | Disable auto-pagination | | `--rsh-no-cache` | Disable the HTTP cache | | `--rsh-ignore-status-code` | Do not set the exit code from the HTTP status code | | `--rsh-insecure` | Disable SSL verification | | `--rsh-ca-cert string` | Path to a PEM-encoded CA cert | | `--rsh-client-cert string` | Path to a PEM-encoded client certificate | | `--rsh-client-key string` | Path to a PEM-encoded private key | | `--rsh-retry int` | Number of times to retry on certain failures (default `2`) | | `-t, --rsh-timeout duration` | Timeout for HTTP requests | | `-v, --rsh-verbose` | Enable verbose log output | | `--service-account string` | Authenticate with a [service account](https://docs.apicontext.com/cli/reference/authentication.md#service-accounts) file instead of a browser login. Env: `APIMETRICS_SERVICE_ACCOUNT` | | `--project-id string` | Use this project for the run, overriding the selected project. Env: `APIMETRICS_PROJECT_ID` | | `--version` | Print the CLI version, OpenAPI spec version, and last spec check date | | `-h, --help` | Help for the command | ## JSON output is `-o json`, not `--json` There is **no `--json` flag**. To get machine-readable JSON, use the output-format flag: ```bash # Correct apimetrics list-monitors -o json # Also valid (long form) apimetrics list-monitors --rsh-output-format json ``` ## There is no `api configure` The CLI does not register an `api configure` command or the generic HTTP verb commands (`get`, `post`, …). To authenticate, use [`login`](https://docs.apicontext.com/cli/reference/authentication.md) instead of `api configure`. To call the API, use the [generated per-operation commands](https://docs.apicontext.com/cli/generated-commands.md). ## Examples ```bash # Pretty table (default) vs. JSON apimetrics list-monitors apimetrics list-monitors -o json # Add a custom header and override the server for one call apimetrics list-monitors -H 'X-Trace: 1' -s https://staging.example.com # Filter results client-side apimetrics list-monitors -f 'body.data[].name' ``` ## Shell completion The `completion` command generates an autocompletion script for `bash`, `zsh`, `fish`, or `powershell`. ```bash # Print the completion script for your shell apimetrics completion zsh ``` Run `apimetrics completion <shell> --help` for instructions on loading the script in your shell. ## See also - [Authentication](https://docs.apicontext.com/cli/reference/authentication.md): profiles use `-p/--rsh-profile` - [Generated commands](https://docs.apicontext.com/cli/generated-commands.md) --- # API Reference > APImetrics REST API reference for authentication, monitors, schedules, workflows, results, reports, and more. Source: https://docs.apicontext.com/reference Use the API reference to manage API calls, authentication settings, schedules, workflows, results, reports, and other resources programmatically. Start with the [API reference overview](https://docs.apicontext.com/reference/intro.md), then browse the endpoint groups in the sidebar. --- # API Reference > APIContext REST API versions, authenticated Try-It, first-call walkthrough, and full OpenAPI downloads. Source: https://docs.apicontext.com/reference/intro Use APIContext's REST API to manage monitors, schedules, workflows, results, analytics, and more. The full generated reference covers both **API v2 and API v3**, and operation pages offer a browser-based **Send API Request** panel. ## Start here - [Make your first API call](https://docs.apicontext.com/reference/try-it.md) with a read-only operation and a disposable test credential. - [Browse API v3 monitors](https://docs.apicontext.com/reference/api-full/list-api-monitors) and [legacy v2 calls](https://docs.apicontext.com/reference/api-settings/list-all-calls). - [Inspect v3 schedules](https://docs.apicontext.com/reference/api-full/list-schedules) and [v2 schedules in the complete contract](https://docs.apicontext.com/reference/api-full/list-schedules-v-2); the [curated v2 view](https://docs.apicontext.com/reference/api-settings/list-schedules) is also retained. - [Use APIContext with a coding agent](https://docs.apicontext.com/reference/agent-integration.md). ## Authentication Send an API key in the `Authorization` header as `Bearer <your API key>`. Generate one from **Settings → API Key Access** in the [APIContext dashboard](https://client.apimetrics.io); see [Using the APIContext API](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md). The complete reference also lists OAuth2 and an `X-Api-Key` header. The in-browser **Send API Request** panel accepts only the `Authorization` header. Use only test credentials in the in-browser panel. It works on docs.apicontext.com only: see [Make your first API call](https://docs.apicontext.com/reference/try-it.md). ## API versions | Version | API origin | Coverage | | --- | --- | --- | | **v2** | `https://client.apimetrics.io/api/2` | Existing calls, schedules, workflows, and other legacy operations | | **v3** | `https://client.apimetrics.io/api/3` | Monitors, schedules, organizations, analytics, and more | | OAuth token endpoint | `https://apimetrics.auth0.com` | Separately documented token flow | The [complete reference](https://docs.apicontext.com/reference/api-full/apimetrics) contains all the approved v2 and v3 paths in one contract. The [settings API reference](https://docs.apicontext.com/reference/api-settings/api-settings) and [curated v3 reference](https://docs.apicontext.com/reference/api-v3/api-v-3) are retained for compatibility; neither is the complete API catalog. ## Download OpenAPI - [Complete v2 + v3 OpenAPI JSON](https://docs.apicontext.com/openapi/api3-full.json): the **primary integration contract**. - [Curated settings API JSON](https://docs.apicontext.com/openapi/api-settings.json). - [Curated v3 API JSON](https://docs.apicontext.com/openapi/api-v3.json). - [OAuth token endpoint JSON](https://docs.apicontext.com/openapi/token-endpoint.json). Use [the first-call guide](https://docs.apicontext.com/reference/try-it.md) for the interactive request flow and [pagination](https://docs.apicontext.com/reference/pagination.md) for collection responses. --- # Authentication Object > Description of the JSON for an Authentication Setting. Source: https://docs.apicontext.com/reference/authentication-settings/authentication-object Authentication Settings define the requirements to successfully make an API Call, for example, OAuth Settings.\ Example: ```json { "keys": { "client_secret": null, "client_id": null }, "meta": { "domain": "httpbin.org", "description": null, "created": "2015-09-14T23:19:52.888168Z", "documentation": { "keys": null, "docs": null, "apps": null, "provider": null }, "last_update": "2015-09-14T23:19:52.888175Z", "owner": "agxkZXZ-dmlhdGVzdHNyEQsSBFVzZXIYgICAgICAgAoM", "tags": [], "name": "Minimal Auth Settings name" }, "id": "agxkZXZ-dmlhdGVzdHNyGgsSDVNlcnZpY2VDb25maWcYgICAgKDdjQgM", "settings": { "auth_type": "NONE", "custom_variables": {} } } ``` | Name | Description | required? | | :------- | :---------------- | :-------- | | meta | See section below | Yes | | settings | See section below | Yes | | keys | See section below | No | ## Section: meta | Name | Description | required? | | :------------ | :------------------------------------------------- | :------------- | | name | Name for your reference | Yes | | tags | List of tags for your reference | No | | description | Description for your reference | No | | owner | ID of owner | No - read-only | | domain | The hostname for URLs that use this authentication | No | | documentation | See below | No | ## Section: meta.documentation | Name | Description | required? | | :------- | :------------------------------------------- | :-------- | | keys | Link to developer keys page for site | No | | docs | Link to developer docs for site | No | | apps | Link to developer app creation page for site | No | | provider | Link to homepage for site | No | ## Section: settings | Name | Description | Required | | --- | --- | --- | | auth\_type | Kind of authentication, one of:\ "MANUAL", "BASIC", "OAUTH1", "OAUTH2", "NONE", "OAUTH2\_JWS", "OAUTH2\_JWT", "AMAZON" | Yes | | custom\_variables | Dictionary of custom variables for use in API calls | No | | ... | Other keys may be added depending on the Authentication Type. | No | ```json { "access": { "keys": false, "org_keys": false, "org_settings": false, "settings": false }, "keys": { "client_secret": null, "client_id": null }, "meta": { "domain": "httpbin.org", "description": null, "documentation": { "keys": null, "docs": null, "apps": null, "provider": null }, "owner": "agxkZXZ-dmlhdGVzdHNyEQsSBFVzZXIYgICAgICAgAoM", "tags": [], "name": "Auth Settings update" }, "settings": { "auth_type": "OAUTH2_JWT", "authorize_url": "http://httpbin.org/get", "custom_variables": {} } } ``` --- # Call Object > Description of the JSON for an API Call. Source: https://docs.apicontext.com/reference/api-calls/call-object The API Call object defines the HTTP request we make from a deployment. The request can have an Authentication Setting and Authentication Token applied to it.\ Example object: ```json { "meta": { "domain": "httpbin.org", "description": null, "created": "2015-09-18T23:29:39.534120Z", "tags": [], "accept": null, "last_update": "2015-09-18T23:29:39.534173Z", "content_type": null, "owner": "agxkZXZ-dmlhdGVzdHNyEQsSBFVzZXIYgICAgICAgAoM", "name": "Minimal API test name" }, "request": { "body": null, "parameters": [], "url": "http://httpbin.org/get", "auth_id": null, "headers": [], "token_id": null, "method": "GET" }, } ``` | Name | Description | Required? | | :------ | :---------- | :-------- | | meta | See below | Y | | access | See below | N | | request | See below | Y | ## Section: meta | Name | Description | Required? | | :---------- | :------------------------------------------- | :------------- | | name | Name of the call for your reference | Yes | | description | Description of the call for your reference | No | | tags | List of Tags for the call for your reference | No | | owner | The ID of the Owner of the call | No - read-only | ## Section: request | Name | Description | Required? | | :--------- | :---------------------------------------------------------- | :-------- | | method | HTTP method to use | Y | | url | URL to call | Y | | parameters | List of request parameters to append to the call | N | | headers | List of headers to include in the call | N | | body | Content of a POST or PUT call | N | | auth\_id | The ID of the authentication settings to use | N | | token\_id | The ID of the token to use with the authentication settings | N | --- # Insights Report Object > Description of the JSON for an Insights Report. Source: https://docs.apicontext.com/reference/insights/insights-report-object Insights Object | Key | Description | Example Value | | --- | --- | --- | | domain | The domain name for the API call | " [www.example.com"](http://www.example.com") | | name | The name of the API Call | Example API Call Name | | start\_date | Start date for the Insights Report | "2018-08-20T00:00:00Z" | | end\_date | End date for the Insights Report | "2018-08-27T00:00:00Z" | | outlier\_percent | Percentage of Outliers found | 1.349340212322651 | | id | The ID of the Report | {''} | | call\_id | Call ID | {''} | | mean\_test\_length | Mean Total Latency of the API Call in the Report Period | 688.93734991990391 | | report\_type | The Report is Monthly if 0, or Weekly if 1 | 1 | | score | CASC Score | 759 | | pass\_percent | Percentage of Passing API calls in the Report Period | 99.097132652048813 | | sd\_test\_length | Standard Deviation of the API calls for the Report Period | 473.742535583235 | --- # List Org-level Downtimes > Use this API to retrieve a comprehensive list all Downtime configurations across your Organization's projects. Source: https://docs.apicontext.com/reference/org-level-downtimes/list-org-level-downtimes > **Replace \[ \[[Access_Tok** --- # Refresh Token Flow > If your APImetrics Access token has expired, use this refresh token flow to generate a new Access token. Source: https://docs.apicontext.com/reference/refresh-tokens/refresh-token-flow --- # Report Object > Description of the JSON for a Result. Source: https://docs.apicontext.com/reference/reports/report-object Reports are groups of API Calls and Locations, they are used to show statistics at specific times. This object defines how they are configured. | Name | Description | Required? | | :----- | :---------- | :-------- | | meta | See below | Y | | report | See below | Y | ## Section: meta | Name | Description | Required? | | :---------- | :-------------------------------------------- | :------------- | | name | Name of call, for your reference | Yes | | description | Description of call, for your reference | No | | tags | List of tags for the call, for your reference | No | | owner | The ID of the Report Owner | No - read-only | | Name | Description | Required? | | :----- | :------------------------------------------- | :-------- | | public | Is the report with the APImetrics community? | N | | org | Is the report shared with your Organization? | N | ## Section: groups The section "groups" is a list of the following objects: | Name | Description | Required? | | :--- | :---------- | :-------- | | name | Group Name | Y | | rows | See below | N | ## Section: rows The section "rows" is a list of the following objects: | Name | Description | Required? | | :----------- | :------------------------------------------------------------- | :-------- | | call\_id | The ID of the API Call you want to see the stats for. | Y | | location\_id | The ID of the deployed location you want to see the stats for. | Y | --- # Result Object > Description of the JSON for a Result. Source: https://docs.apicontext.com/reference/results/result-object The Result object contains the request to an endpoint, the response from the endpoint, and the timing meta-data. The list APIs only return the meta-data, to view the request or response data, you need to get the individual Result object. ```json { "timing": { "handshake": 0.0, "total": 30.269, "dns": 4.249, "download": 18.945, "processing": 0.016, "upload": 0.034, "tcp": 7.025 }, "meta": { "result_category": "PASS", "domain": "google.apimetrics.xyz", "url": "http://google.apimetrics.xyz/post", "source_ip": "172.31.16.88", "request_size": 27, "call_id": "ag9zfmFwaW1ldHJpY3MtcWNyEwsSClRlc3RTZXR1cDIYofqRDAw", "result": "COMPLETE", "response_size": 746, "http_code": 200, "location_id": "public_qcawsuswest", "id": "ag9zfmFwaW1ldHJpY3MtcWNyGAsSC1Rlc3RSZXN1bHQzGICAwPbMrdEIDA", "dest_ip": "35.190.18.183" }, "request": { "url": "http://google.apimetrics.xyz/post", "headers": [ { "value": "k2=v2; k1=v1", "key": "Cookie" }, { "value": "application/x-www-form-urlencoded", "key": "Content-Type" }, { "value": "application/json", "key": "Accept" }, { "value": "APImetrics/0.9.1 PycURL/7.43.0.3 libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3", "key": "User-Agent" } ], "method": "POST" }, "response": { "url": "http://google.apimetrics.xyz/post", "headers": [ { "value": "gunicorn/19.7.1", "key": "Server" }, { "value": "Sat, 22 Aug 2020 00:03:41 GMT", "key": "Date" }, { "value": "application/json", "key": "Content-Type" }, { "value": "*", "key": "Access-Control-Allow-Origin" }, { "value": "true", "key": "Access-Control-Allow-Credentials" }, { "value": "746", "key": "Content-Length" }, { "value": "1.1 google", "key": "Via" } ], "status_string": "OK", "status_code": 200 }, "id": "ag9zfmFwaW1ldHJpY3MtcWNyGAsSC1Rlc3RSZXN1bHQzGICAwPbMrdEIDA" } ``` | | | | | :------- | :------------ | :----------------- | | id | The Result ID | | | meta | Meta-data | | | request | Request data | (Not in list APIs) | | response | Response data | (Not in list APIs) | | timing | Timing data | | ## Section: meta ## Section: timing | | | | | :--------- | :---------------------------------------------------------------------------------------------------------------------------------------------- | :------------------- | | total | The total time it took to make the API call | Time in milliseconds | | dns | The time to look up the IP address using DNS | Time in milliseconds | | tcp | The time to make a TCP connection | Time in milliseconds | | handshake | The time to make the SSL handshake (if needed) | Time in milliseconds | | upload | The time between the first byte and the last byte sent to the endpoint | Time in milliseconds | | processing | The time between the last byte being sent to the endpoint, and the first byte received back in response. Sometimes known as Time to First Byte. | Time in milliseconds | | download | The time it took to receive the full response. | Time in milliseconds | ## Section: request | | | | | :------ | :-------------------- | :---------------------------------------------------------- | | method | The HTTP method used | e.g. GET, POST, etc | | url | The URL requested | e.g. [http://google.apimetrics.xyz/post](http://google.apimetrics.xyz/post) | | headers | The HTTP headers sent | An array of dictionaries with key and value for each header | ## Section: response | | | | | :------------ | :-------------------------------------------------------------------- | :---------------------------------------------------------- | | status_code | The HTTP status code of the response | e.g. 200 | | status_string | The HTTP status string, if any | e.g. OK | | url | The final URL requested (may be different if redirects were followed) | e.g. [http://google.apimetrics.xyz/post](http://google.apimetrics.xyz/post) | | headers | The HTTP headers received | An array of dictionaries with key and value for each header | --- # Statistic Object > Description of the JSON for a Statistic. Source: https://docs.apicontext.com/reference/api-call-latency-statistics/statistic-object Statistics are generated each time an API Call is made, per call per location. Aggregated statistics are also generated for the hour, day, week, month and year (all based on UTC).\ Example: ```json { "meta": { "kind": "MONTH", "call_id": "agxkZXZ-dmlhdGVzdHNyFwsSClRlc3RTZXR1cDIYgICAgKDDxwgM", "type": "ALL", "time": "2015-10-01T00:00:00Z", "location_id": "", "name": "API test name" }, "stat": { "avg_latency": 383.5, "max_latency": 749, "time": "2015-10-01T00:00:00Z", "count": 20 } } ``` Data available for all results: | Name | Type | Description | | :----------- | :------- | :-------------------------------------------------------------- | | time | DateTime | Normalized time for the period requested. | | count | Integer | The number of API calls made in the specified period. | | max\_latency | Integer | The slowest API Call made in the specified period in ms. | | avg\_latency | Float | The average latency for the API Calls for the specified period. | Extra data is available for results that passed (i.e. when type is set to COMPLETE). | Name | Type | Description | | :------------------ | :------- | :--------------------------------------------------------------------- | | time | DateTime | Normalized time for the period requested. | | count | Integer | The number of API Calls made in the specified period. | | max\_latency | Integer | The slowest API Call made in the specified period in ms. | | min\_latency | Integer | The fastest API Call made in the specified period in ms. | | avg\_latency | Float | The average latency for the API Calls for the specified period. | | standard\_deviation | Float | The standard deviation of API Call latencies for the specified period. | | skewness | Float | The skewness of API Call latencies for the specified period. | Data that is available when requesting raw data, i.e. kind = RAW. | Name | Type | Description | | :-------------- | :------- | :--------------------------------------------------------- | | time | DateTime | The time that the API Call was made. | | latency | Integer | The length of time, in ms, that the API Call took to make. | | http\_code | Integer | The HTTP response code returned. | | content\_length | Integer | The size, in bytes, of the response. | --- # Token Object > Description of the JSON for a Token. Source: https://docs.apicontext.com/reference/authentication-tokens/token-object Some Authentication schemes generate a token. This object stores that information. An Authentication Setting can have many Tokens. | Name | Description | Required? | | :------------ | :------------------------------------------------------------------------------------- | :-------- | | meta | See below | Y | | token | See below | N | | api\_response | Object containing the response of the API call that created this token (for JSON APIs) | N | ## Section: meta | Name | Description | Required? | | :------- | :--------------------------------------------------------------------------- | :------------ | | name | Name of the token, for your reference. | Y | | owner | The ID of the owner | N - read-only | | domain | The hostname of the site for the authentication (e.g. client.apimetrics.com) | N - read-only | | auth\_id | ID for the Authentication Settings | Y | ## Section: token | Name | Description | Required? | | :----------- | :--------------------- | :-------- | | expire\_time | Time the token expires | N | --- # Workflow Object > Description of the JSON for a Workflow. Source: https://docs.apicontext.com/reference/workflows/workflow-object Workflows are a list of API Calls that are called one after the other. This object defines how they are configured. | Name | Description | Required? | | :------- | :---------- | :-------- | | meta | See below | Y | | access | See below | N | | workflow | See below | Y | ## Section: meta | Name | Description | Required? | | :---------- | :-------------------------------------------- | :------------- | | name | Name of call, for your reference | Yes | | description | Description of call, for your reference | No | | tags | List of tags for the call, for your reference | No | | owner | The ID of the Call Owner | No - read-only | ## Section: access | Name | Description | Required? | | :----- | :---------------------------------------------------- | :-------- | | public | Is the workflow shared with the APImetrics community? | N | | org | Is the workflow shared with your Organization? | N | ## Section: workflow | Name | Description | Required? | | :---------------- | :------------------------------------------------------------------------- | :-------- | | call\_ids | List of API Call IDs in the order you want them called | N | | stop\_on\_failure | Should the workflow stop if we get an error response from one of the APIs? | N | | handle\_cookies | Should cookies be handled and passed between API calls? | N | --- # Make your first API call > A read-only APIContext REST request from the docs' interactive API Explorer with a test credential. Source: https://docs.apicontext.com/reference/try-it The API Reference includes an in-browser request panel. It is intended to make **real HTTP requests** to the API, not demonstrate a static example. > **Do not enter production secrets** > > Use a **disposable, scoped test credential** and a dedicated, revocable test account. This docs configuration disables persistence of Try-It credentials in local and session storage, so you may need to enter them again on another page. Do not share unredacted network captures or screenshots. ## Prerequisites 1. Sign in to the [APIContext dashboard](https://client.apimetrics.io) and obtain an API credential for a nonproduction project, or ask your administrator. 2. Send the key in the `Authorization` header as `Bearer <your API key>`, the same format as [Using the APIContext API](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md). The in-browser panel works only with the `Authorization` header: the API does not accept an `X-Api-Key` header from a browser. 3. Use only safe, read-only GET operations for the first call. ## Step 1: Open the reference page Open [List All API Calls (v2)](https://docs.apicontext.com/reference/api-settings/list-all-calls). Its GET request has no mandatory path parameters. To explore v3, open [List API Monitors](https://docs.apicontext.com/reference/api-full/list-api-monitors). ## Step 2: Authorize Use the **Auth** section of the request panel on the right: - On the v2 and v3 pages (for example, List All API Calls), enter `Bearer <your API key>` in the **ApiKeyAuth** field. - On the complete-reference pages (`/reference/api-full/...`), choose **OAuth2** and paste your API key as the bearer token. Do not choose **ApiKey**: it sends `X-Api-Key`, which the browser blocks. Check the generated request before sending: it must show `Authorization: Bearer ...`. ## Step 3: Fill in parameters For the v2 list-calls example, no path parameter is required. On other pages fill in the marked path, query, or header parameters. For example, the curated [v3 organization downtimes listing](https://docs.apicontext.com/reference/api-v3/list-org-level-downtimes) requires an organization ID. ## Step 4: Send the request Click **Send API Request** in the browser panel. Inspect the HTTP status and response body. The v2 example must send a request to `https://client.apimetrics.io/api/2/calls/`. A successful list GET usually returns status 200 and response data. The panel works on docs.apicontext.com only. The API accepts browser requests from that site, so a copy of these docs served from another address (a local build or a preview) gets a network error. ## Troubleshooting | Symptom | Check | | --- | --- | | 401 Unauthorized | Correct security scheme, credential, and Bearer prefix if applicable | | 403 Forbidden | Account/project permissions | | 400 or 422 | Missing or malformed required query, path, or header parameter | | Network error, nothing in the response panel | You chose **ApiKey** (`X-Api-Key`) instead of the `Authorization` header, or the page is not on docs.apicontext.com | | No send button | Confirm the API Explorer panel loaded and report the exact page to the documentation team | ## See also - [Complete API reference](https://docs.apicontext.com/reference/intro.md) - [Pagination](https://docs.apicontext.com/reference/pagination.md) - [Integrate with a coding agent](https://docs.apicontext.com/reference/agent-integration.md) --- # Get a token and try an endpoint > Preserved legacy first-call URL linking to the canonical browser walkthrough and correct credential guidance. Source: https://docs.apicontext.com/reference/get-a-token-and-try-an-endpoint The canonical walkthrough is [Make your first API call](https://docs.apicontext.com/reference/try-it.md). It covers read-only browser requests, operation-specific authentication, and CORS troubleshooting. ## Step 1: Get your API key Follow the [prerequisites](https://docs.apicontext.com/reference/try-it.md#prerequisites) for a revocable test credential. ## Step 2: Authorize the console Follow [the current authorization instructions](https://docs.apicontext.com/reference/try-it.md#step-2-authorize), using the security scheme declared by your chosen operation. ## Step 3: Send a request Follow [the Send API Request steps](https://docs.apicontext.com/reference/try-it.md#step-4-send-the-request). --- # Use APIContext with a coding agent > Full APIContext OpenAPI specification and a safe integration workflow for AI coding agents. Source: https://docs.apicontext.com/reference/agent-integration The primary source is the [complete approved OpenAPI JSON](https://docs.apicontext.com/openapi/api3-full.json). It covers API v2 and v3 and includes operations, parameters, schemas, error responses, and security requirements. The smaller curated downloads are incomplete subsets. 1. Fetch and parse `https://docs.apicontext.com/openapi/api3-full.json`; do not scrape generated HTML as the contract. 2. Choose a **read-only GET** initially, such as `GET /api/3/monitors/api/` or the legacy `GET /api/2/calls/`. Use the operation ID and method/path in the spec, not guesses. 3. Combine the declared server `https://client.apimetrics.io` with the **full** versioned path. Do not prepend /api/2 or /api/3 twice. 4. Read the operation's security requirement and `components.securitySchemes`. The full contract currently declares OAuth2 and X-Api-Key; some compatibility references use an Authorization header. Do not invent or hardcode credentials. 5. Read required parameters and success/error schemas, paginate where necessary, and test with a user-authorized nonproduction project. ## Example task for a coding agent > Build a CLI that lists my API monitors using the complete API v3 contract. Read credentials from environment variables; do not log them or store them in source. Validate required parameters, support pagination, and handle 401, 403, 429, and transient failures. Do not modify or delete any remote data. The account/project identifiers and credentials must be supplied by an authorized user. A coding agent cannot bypass API access controls. ## Additional resources - [Human API overview](https://docs.apicontext.com/reference/intro.md) - [Read-only first-call guide](https://docs.apicontext.com/reference/try-it.md) - [Full documentation text](https://docs.apicontext.com/llms-full.txt) - [AI documentation index](https://docs.apicontext.com/llms.txt) --- # Create Org-level Downtime > Use this API to create downtime configuration across one or more projects within your Organization. Source: https://docs.apicontext.com/reference/org-level-downtimes/create-org-level-downtime > **Replace \[ \[[Access_Tok** --- # Pagination and Error Conventions > How APIContext API responses are paginated and how errors are shaped — cursor-based pagination, error_msg fields, and status codes. Source: https://docs.apicontext.com/reference/pagination This page documents the response conventions used by the APIContext REST API (v2 and v3). ## Pagination The APIContext API uses **cursor-based pagination** for list endpoints. ### Request parameters | Parameter | Type | Description | |---|---|---| | `page_size` | integer | Number of items to return (default: varies by endpoint; max: 100) | | `cursor` | string | Opaque cursor value from the previous response's `meta.next_cursor` | ### Response shape All paginated list responses include a `meta` object: ```json { "data": [ ... ], "meta": { "more": true, "next_cursor": "eyJpZCI6MTIzfQ==", "total_count": 847 } } ``` | Field | Type | Description | |---|---|---| | `meta.more` | boolean | `true` if there are additional pages; `false` when you have reached the last page | | `meta.next_cursor` | string | Pass as the `cursor` query parameter in the next request. Present only when `more` is `true`. | | `meta.total_count` | integer | Total number of items across all pages (where available) | ### Iterating all pages ```python cursor = None while True: params = {"page_size": 100} if cursor: params["cursor"] = cursor resp = requests.get("/api/2/calls/", params=params, headers=headers) data = resp.json() process(data["data"]) if not data["meta"]["more"]: break cursor = data["meta"]["next_cursor"] ``` ## Create responses Successful `PUT` create requests return **HTTP 201 Created** (not 200) with the created object in the body. ## Error shape All error responses use a consistent JSON body: ```json { "error_msg": "Human-readable description of what went wrong", "error_code": "MACHINE_READABLE_CODE" } ``` | Field | Type | Description | |---|---|---| | `error_msg` | string | Human-readable explanation. Always present on error responses. | | `error_code` | string | Machine-readable error identifier. Use this for programmatic error handling. | ### Common HTTP status codes | Code | Meaning | |---|---| | `200` | Success (for updates and reads) | | `201` | Created (for `PUT` create operations) | | `400` | Bad request — `error_msg` explains the validation failure | | `401` | Unauthorized — API key missing or invalid | | `403` | Forbidden — key is valid but lacks permission | | `404` | Not found — resource does not exist | | `429` | Rate limited — retry after the `Retry-After` header value | | `500` | Server error — retry with exponential backoff | ## See also - [API Reference overview](https://docs.apicontext.com/reference/intro.md) - [Using the APIContext API](https://docs.apicontext.com/guides/advanced-features/using-the-apimetrics-api.md) --- # Limits > Limits on workflow steps, stored and displayed response bodies, the Results list, and how long results are kept. Source: https://docs.apicontext.com/reference/limits These limits are the same on every plan. ## Workflows | Item | Limit | |---|---| | Steps (monitors) in one workflow | No maximum | | Runs of one workflow at a time | Unlimited, unless **Ensure the workflow does not run in parallel** is on. See [Preventing parallel runs](https://docs.apicontext.com/guides/creating-a-workflow/workflows-edit.md#preventing-parallel-runs). | ## Response bodies | Item | Limit | |---|---| | Stored response body, APIContext nodes | No size limit. The full body is kept. | | Stored response body, private nodes without cloud storage | Text bodies over 32,000 bytes are cut to 32,000 bytes and end with `<< TRUNCATED >>`. Binary bodies are not stored. See [Add Private Nodes](https://docs.apicontext.com/guides/add-private-nodes.md#response-bodies). | | Response body shown on a result | JSON bodies are formatted and shown up to the first 1,000 lines. A longer body is hidden at first: select **Show Response Body** to load all of it. **Download** always gives the full stored body. | ## Results | Item | Limit | |---|---| | Results listed | No fixed number. The Results list loads the results for the time range you pick, 2,500 at a time, and loads more as you need them. | | Result summary (time, location, outcome, status code, timings, sizes) | Kept with no end date. The Results list and statistics are built from it. | | Full result details and the stored response body | Kept for the current and the previous calendar month, so between about 31 and 62 days depending on the day the result ran. After that the result stays in the list, but its full details and body are gone. | To keep a response body for longer, download it from the result while it is still stored. --- # Update Org-level Downtime > Use this API to update existing downtime configuration. Source: https://docs.apicontext.com/reference/org-level-downtimes/update-org-level-downtime > **Replace \[ \[[Access_Tok** --- # Delete Org-level Downtime > Use this API to delete an Org-level Downtime Source: https://docs.apicontext.com/reference/org-level-downtimes/delete-org-level-downtime > **Replace \[ \[[Access_Tok** --- # Get Monthly Project Data Report > Use this API to get a monthly report for your project. Source: https://docs.apicontext.com/reference/reports/get-monthly-project-data-report > **Replace \[\[app:key** Note: this API will return CSV data if you set the Accept header to text/csv --- # Get Daily Project Slow Data Report > Use this API to retrieve slow data reports for all projects within a date range Source: https://docs.apicontext.com/reference/reports/get-daily-project-data-report > **Replace \[\[app:key** Note: this API will return CSV data if you set the Accept header to text/csv This API returns a list of Projects with the total counts of passes, slows (of various thresholds), warning and failures per day, grouped by project and day. --- # Get Monthly Project Slow Data Report by Endpoint > Get a monthly slow data report for each monitor across all projects in an organization, with call counts by response time threshold. Source: https://docs.apicontext.com/reference/reports/get-monthly-project-slow-data-report > **Replace \[\[app:key** This API returns a report for one calendar month. It has one row for each monitor, grouped by project and month, with the monitor's total counts of passes, slow calls at each response time threshold, warnings, and failures. It also gives the monitor's name and the URL it calls. The report covers every project in the organization, even when you authenticate with the API key of a single project. Rows for monitors and projects that have since been deleted are left out. To get monthly data for one project, use [Get Monthly Project Data Report](https://docs.apicontext.com/reference/reports/get-monthly-project-data-report.md), which has no slow breakdown. ## Request ```text GET https://client.apimetrics.io/api/3/organizations/{org_id}/analytics/slow-calls-monthly ``` | Name | In | Required? | Description | | :--- | :-- | :-------- | :---------- | | `org_id` | Path | Yes | The Organization ID that owns all the projects. | | `start_date` | Query | Yes | The month to report on, as an ISO 8601 date such as `2024-07-01`. | | `thresholds` | Query | No | Response times in milliseconds that divide slow calls into bands. Repeat the parameter for each value, for example `thresholds=700&thresholds=800`. Give at least two values. The default is 700, 800, 900, 1000, and 2000. | | `Accept` | Header | No | Set to `text/csv` to receive CSV instead of JSON. | ## Response The JSON response has a `meta` object and a `data` array. The `meta` object holds `report_type` (`slow_calls_monthly`), `version`, `start_date`, `end_date`, and `created_at`. Each item in `data` is one monitor for one month. The CSV response has one column for each field below, in the same order. | Field | Type | Description | | :---- | :--- | :---------- | | `month` | Date | The first day of the month the row covers. | | `project_id` | String | The name of the project that owns the monitor. | | `test_id` | String | The name of the monitor. | | `url` | String | The URL the monitor calls. | | `pass_count` | Integer | Calls that passed or were slow, and responded faster than the lowest threshold. | | `slow<threshold>_count` | Integer | One field for each threshold, such as `slow700_count`. Calls that passed or were slow, with a response time at or above the threshold and below the next threshold. For the highest threshold, the count has no upper limit. | | `warn_count` | Integer | Calls with a warning result. | | `fail_count` | Integer | Calls that failed. | | `total` | Integer | All calls for the monitor in the month. | The slow counts are bands, not running totals. With the thresholds 700 and 800, `slow700_count` holds calls from 700 ms up to, but not including, 800 ms, and `slow800_count` holds calls of 800 ms or more. To count every call of 700 ms or more, add the two fields. > **Note** > > The OpenAPI schema describes the slow counts as a `slow_counts` object keyed by threshold. The JSON and CSV responses return each count as its own `slow<threshold>_count` field. ## Example A request with the thresholds 700 and 800 returns rows like this one: ```json { "meta": { "report_type": "slow_calls_monthly", "version": 1, "start_date": "2024-07-01", "end_date": "2024-08-01", "created_at": "2024-08-19T22:11:46.125494" }, "data": [ { "month": "2024-07-01", "project_id": "Example Project", "test_id": "Webhooks List", "url": "https://api.example.com/webhooks", "pass_count": 4411, "slow700_count": 3, "slow800_count": 18, "warn_count": 0, "fail_count": 1, "total": 4433 } ] } ``` --- # Release Notes - 9 November 2026 > Release notes for APIContext, 9 November 2026: MCP step baselines, a fuller create panel, CLI sign-in, API enhancements, fixes, and security updates. Source: https://docs.apicontext.com/changelog/release-notes-9-november-2026 This release adds baselines for MCP monitor steps, more fields in the panel for creating a monitor, and enhancements to the API, along with bug fixes and security updates. ## Added: MCP step baselines * **Mark as Expected:** on an MCP monitor result, mark a step's result as expected. Later results of that step are checked against it, and differences show as Data issues on the Conformance page. You choose which parts of the result are allowed to change, such as tool descriptions. * **Accept as Expected:** when a server changes on purpose, accept the new result as the baseline from the Data issue. ## Updated: Creating monitors * The **Create New API Call** panel now takes query parameters, headers, an auth setting and token, and a body for `POST`, `PUT`, and `PATCH`. If you leave the name empty, the monitor is named after the method and URL. See [Add an API monitor](https://docs.apicontext.com/guides/add-a-monitor/add-api-call.md). * The **Create MCP Monitor** panel now takes an auth setting and token. See [MCP monitors](https://docs.apicontext.com/guides/add-a-monitor/mcp-monitors.md). ## Updated: Monitor pages On a project's performance page, the API tables list API monitors only, and the browser table shows DNS lookup, TCP connect, and SSL handshake times. ## Updated: CLI sign-in A browser or device-code login now renews itself in the background while you use the CLI. Sign in again after 3 days without using it, or 7 days after you signed in. See [CLI authentication](https://docs.apicontext.com/cli/reference/authentication.md). ## Updated: API This release includes enhancements and improvements to the API. See the [API reference](https://docs.apicontext.com/reference/api-full/apimetrics). ## Bug fixes, enhancements, and improvements This release includes various bug fixes, enhancements, and improvements across the platform. ## Security updates This release includes security updates. --- # Release Notes - 22 October 2026 > Release notes for APIContext, 22 October 2026: API enhancements, CLI 0.0.2 with device code login, bug fixes, and security updates. Source: https://docs.apicontext.com/changelog/release-notes-22-october-2026 This release covers enhancements to the API, version 0.0.2 of the CLI, bug fixes, and security updates. ## Updated: API This release includes enhancements and improvements to API v3 for API monitors. See the [API monitors reference](https://docs.apicontext.com/reference/api-full/api-monitors). ## Updated: CLI 0.0.2 * **Device code login:** `apimetrics login --device` signs you in by confirming a code in a browser on any device, for example when you work over SSH. * **Longer sessions:** browser logins now receive a refresh token, so you sign in less often. * **More reliable requests:** improved handling of request timeouts and retries. Upgrade through Homebrew, winget, or the GitHub release assets. See [Install the CLI](https://docs.apicontext.com/cli.md). ## Bug fixes, enhancements, and improvements This release includes various bug fixes, enhancements, and improvements across the platform. ## Security updates This release includes security updates. --- # Release Notes - 8th of October 2026 > Release notes for APIContext, 8 October 2026: China monitoring nodes. Source: https://docs.apicontext.com/changelog/release-notes-8th-of-october-2026 This release covers China monitoring nodes. ## Added: China monitoring nodes China monitoring nodes run API and HTTP tests. They are included in every plan. * China is a separate region from Asia. Neither Asia nor Worldwide includes China. * To enable China nodes, submit a support request through the [APIContext support page](https://apicontext.com/support). After they are enabled, configure monitors through the UI, API, or CLI. * Results from China nodes use your project's existing alerts, triggers and webhooks. --- # Release Notes - 30th of September 2026 > Release notes for APIContext, 30 September 2026: rebuilt report pages with drag-and-drop ordering and an embeddable status frame, a statistic picker, and CLI updates. Source: https://docs.apicontext.com/changelog/release-notes-30th-of-september-2026 This release covers rebuilt report pages, a statistic picker for latency, and updates to the CLI. ## Added: Rebuilt report pages with drag-and-drop ordering Report view and edit pages have been rebuilt and are faster to load. * Reorder groups and monitors in the report editor by dragging and dropping. Rows appear in the order you set in the editor. * The location column has been removed from report tables. Location breakdowns are still available in the location breakdown table. * Report statistics load through the aggregate endpoints, and CSV downloads use the new backend endpoints. ## Added: Embeddable public report status frame Public reports now use a standalone status frame with an embed script, so you can embed a live report status in your own site. The **Share** panel points to the new frame URL, and existing public report links redirect to it. ## Added: Statistic picker for latency Choose which statistic to display in the monitor stats view: mean, or the 90th, 95th, or 99th percentile. ## Added: MCP error result types MCP monitor results now distinguish **MCP Transport Error** from **MCP server returned an error**. ## Updated: CLI * **Service account authentication:** use `--service-account <file>` (or `APIMETRICS_SERVICE_ACCOUNT`) to run the CLI from CI and other headless environments, and `--project-id` (or `APIMETRICS_PROJECT_ID`) to choose a project for a single run. * **Claude Code skills and AGENTS.md:** `apimetrics skills install --claude-skills` installs eight operational skills for AI coding agents. * **Windows and Homebrew support**, with binaries published as GitHub release assets. * `--version` now also reports the OpenAPI spec version and last-check date. ## Added: Organization administration Site admins can create organizations and edit organization and project settings from the admin sidebar. The project page now shows the organization name. ## Fixed: Sessions and authentication Improved session handling across a variety of use cases. ## Fixed: Variables, webhooks and monitor results * Account variables with more than 100 entries now load correctly. * Webhooks with unset parameters are highlighted as incomplete. * Improved timing waterfall. --- # Release Notes - 25th of August 2026 > Release notes for APIContext, 25 August 2026: service account management, rebuilt notifications page, agent-type badges, and authentication fixes. Source: https://docs.apicontext.com/changelog/release-notes-25th-of-august-2026 This release introduces service account management, a rebuilt notifications page, workflow editor improvements, and several fixes to authentication and download handling. ## Added: Service account management Create and manage service accounts directly from Organization Settings. Service accounts provide client credentials for machine-to-machine API access without tying authentication to an individual user. - Create service accounts with a generated client ID and client secret - Assign and manage roles per service account - Rotate secrets at any time from the service accounts table - Download credentials as JSON or copy to clipboard - The client secret is displayed once at creation; rotate to generate a new one Available to organization admins in **Settings > Service Accounts**. ## Added: Rebuilt notifications page The Issue Notifications page has been rebuilt with improved filtering, navigation, and performance. - Filter notifications by category and date range - Select your preferred timezone for displayed dates - Cursor-based pagination for faster loading on large notification lists - Click any notification to open an inline detail sidebar with links to related monitors, results, and workflows - Notifications are automatically marked as viewed when opened ## Improved: Agent-type badges in the workflow location picker The location selector in the workflow editor now displays colored badges indicating the type of each monitoring agent (API, Browser, or MCP) making it easier to identify and select the right location for your workflow steps. ## Fixed: Downloads now work with token-based authentication Result content and file downloads have been updated to use token-based authentication. Previously, some downloads could fail with an authentication error. Download buttons now show a loading indicator while the file is being fetched. ## Fixed: Login no longer hangs on silent authentication failure Resolved an issue where reloading the app with an expired or invalid session could cause the login screen to display "Loading..." indefinitely instead of redirecting to the sign-in page. --- # Release Notes - 10th of July 2025 > Release notes for APImetrics, 10 July 2025: stop all org alerts, visible downtime IDs, bulk update of conformance findings, and navigation fixes. Source: https://docs.apicontext.com/changelog/release-notes-10th-of-july-2025 This release introduces improved alerting functionality and other improved navigation elements. ## Added: Stop all alerts across your organization Pause all alerts when your application or monitoring is in an unhealthy state. - Available for organization admins ## Added: Visible downtime IDs See downtime IDs in the UI to easily update, change, or manage downtimes. ## Added: Bulk update for Conformance findings Update multiple Conformance findings at once. ## Fixed: Various UI fixes for improved navigation --- # Release Notes - 11th of March 2025 > Release notes for APImetrics, 11 March 2025: additional DNS metadata in results and alerts, plus content delivery and geo-fencing conformance checks. Source: https://docs.apicontext.com/changelog/release-notes-11th-of-march-2025 This release expands networking telemetry and conformance use cases to more deeply understand internet routing optimizations and business rules. ## Added: Additional DNS metadata Additional DNS metadata is now available, including CNAMEs and DNS nameservers, which can be used for identifying misconfigurations and troubleshooting. - To add additional DNS information into your results, choose an API Call, select Edit API Call, then select the Advanced button at the top of the page. On the Advanced page, under Advanced Features, select the toggle for Additional DNS Queries. ## Added: DNS information in results and alerts The additional DNS information is available in the API Call Results tab. To see the details, navigate to an individual API call result, navigate to Target IP, and click "More." ![API call result showing additional DNS metadata such as CNAMEs and nameservers under Target IP details](https://docs.apicontext.com/img/310e25c8ba854663f38b66540b37f88b14477d89adeff33a637314b9cdb4c815-Screenshot_2025-03-11_at_15.28.23.webp) - Additional DNS information is also available in Alerts, via OpenTelemetry and Webhooks. Once the data collection is turned on, it will flow to existing alerts automatically. ## Added: Content Delivery conformance check This conformance check ensures against CDN misconfigurations. It analyzes the CDN that was used to deliver the response, and verifies whether the response was delivered from a list of pre-approved CDNs. - To activate, navigate to Conformance, then select the Settings box. Under the Manage Network Checks section, toggle the Enable Content Delivery checks switch to ON. Then select the CDNs that should be used by your endpoints. ![Conformance network checks settings with the Content Delivery check enabled and approved CDNs selected](https://docs.apicontext.com/img/acb508b82e6e75c179ec050b105d84ea45463075d4f6c07c83c1cddb39c1a9d4-Screenshot_2025-03-11_at_15.36.47_copy.webp) ## Added: Geo-fencing conformance check This conformance check ensures against geo-fencing violations. It verifies that your business requirements about where information can be requested from are respected. For example, if you have an application that should only be accessible from the European Union, we will flag any successful calls from Asia or North America. - To activate, navigate to Conformance, then select the Settings box. Under the Manage Network Checks section, toggle the Enable Geo-fencing checks switch to ON. Then add any constraints on where calls should be allowed. Calls will be delivered as expected, and any non-conformances will be flagged as geo-fence failures. ![Conformance network checks settings with the Geo-fencing check enabled and allowed-location constraints](https://docs.apicontext.com/img/f0e12c53ec5a3a0e0100f0c5b79281263355ad58192beace993507d2d4b2333a-Screenshot_2025-03-11_at_15.36.47.webp) --- # Release Notes - 21st of February 2025 > Release notes for APImetrics, 21 February 2025: automated refresh token handling, Payments NZ FAPI checks, and TLS certificate expiration conformance. Source: https://docs.apicontext.com/changelog/release-notes-21st-of-february-2025 This release has a raft of new features focused on hardening advanced refresh token use cases as well as expanding our conformance checks of TLS certificates. ## Added: Automated refresh token refreshing Automated refresh token refreshing is now available for existing and new workflows, ensuring valid refresh tokens are always available. - To enable, choose Workflows from the left hand menu, then select the workflow you want to update. Select the Advanced button at the top of the page, turn ON the opt-in toggle, and click Save. Repeat for each workflow you want to update. ![Workflow Advanced settings with the opt-in toggle for automated refresh token refreshing turned on](https://docs.apicontext.com/img/9a666b39dbee20da7f95fdd32b06e3e0c76edd824672163a238d365d25a3f8b6-Screenshot_2025-02-18_at_12.48.46.webp) ## Improved: Refresh token queue prioritization The back end system will now prioritize API calls with refresh tokens to minimize the time a valid refresh token can be used. ## Improved: Refresh tokens used in multiple workflows While we recommend using a separate refresh token for each workflow, this may not always be possible or desirable. When the same refresh token is used in multiple workflows, the system will now ensure the refresh token handling is synchronized. ## Added: Payments NZ FAPI conformance checks A new conformance check is available for the Payments NZ FAPI implementation requirements, as per the [Payments NZ documentation](https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/294486017/API+Specifications). ## Added: TLS certificate expiration conformance check This new check reviews the TLS certificate on every API call, and flags a non-conformance if the certificate is nearing expiration. - To enable, choose Conformance from the left hand menu, then select the Settings button at the top of the page. Scroll down to Manage Network Checks, click the checkbox to "Notify when TLS certificates are close to expiring," and choose a minimum period. - Review results on the main Conformance page. --- # Release Notes - 7th of February 2025 > Release notes for APImetrics, 7 February 2025: new custom conformance business rules, plus fixes for the alerts snooze button and branch rules. Source: https://docs.apicontext.com/changelog/release-notes-7th-of-february-2025 This release adds custom conformance business rules and fixes for alerting and conformance. ## Added: Custom conformance business rules ## Fixed: Alerts snooze button UI issue ## Fixed: Custom conformance business rules for branches --- # Release Notes - 28th of January 2025 > Release notes for APImetrics, 28 January 2025: expanded geolocation networking telemetry, updated conformance business rules, and an alert snooze fix. Source: https://docs.apicontext.com/changelog/release-notes-28th-of-janaury-2025 This release expands networking telemetry and updates conformance business rules. ## Added: Expanded geolocation networking telemetry Geolocation networking telemetry data is now available for OpenTelemetry and Hydrolix consumption. ## Improved: Conformance business rules Updated conformance business rules functionality. ## Fixed: Alert snooze UI issue Resolved a UI issue that made it difficult to snooze some alerts. --- # Release Notes - 22nd of January 2025 > Release notes for APImetrics, 22 January 2025: daily conformance digest emails, Akamai API Security telemetry integration, and new FAPI conformance checks. Source: https://docs.apicontext.com/changelog/release-notes-22nd-of-january-2025 This release introduces conformance digest emails, Akamai API Security integration, and expanded FAPI conformance checks. ## Added: Daily conformance digest emails Receive daily digest emails for business rules conformance results. ## Added: Akamai API Security telemetry integration Send telemetry into Akamai API Security for first- and third-party APIs. ## Added: FAPI conformance checks - FAPI 1.0 openbanking_uk - FAPI Advanced MTLS - FAPI Advanced Private Key JWT ## Improved: Expanded conformance summary information --- # Release Notes - 12th of June 2024 > Release notes for APImetrics — 12 June 2024: OpenTelemetry and Axiom webhooks, the Conformance beta, uptime monitoring, and new Akamai agent locations. Source: https://docs.apicontext.com/changelog/release-notes-12th-of-june-2024 This release introduces OpenTelemetry webhooks, the Conformance beta, uptime monitoring, and new Akamai agent locations. ## Added: OpenTelemetry and Axiom webhook Create a Webhook for OpenTelemetry & Axiom to send your APImetrics data to Axiom or any vendor that accepts OpenTelemetry. See [our OpenTelemetry webhook tutorial](https://docs.apicontext.com/guides/alerting/expanded-alerting/export-with-opentelemetry.md) on how to add a new webhook today. ## Added: Conformance beta Our Conformance feature has been released in its beta version. Here you can perform a multitude of tasks to see how your APIs conform. - Upload multiple OAS specs on the main Conformance page. We'll match against your API calls and show you if they match your specs, allowing you to realign before the drift becomes too dramatic. ![Conformance Summary beta page prompting to upload an OpenAPI spec, with Schema check not configured](https://docs.apicontext.com/img/9f84154-image.webp) ![Conformance Summary showing 100 percent OpenAPI coverage matching API calls against an uploaded spec](https://docs.apicontext.com/img/6709348-image.webp) - Select from an array of [Security Profiles](https://docs.apicontext.com/concepts/security-profiles.md) in the Conformance settings. Depending on your subscription level, some Security Profiles may be unavailable. For more information, speak to our [sales team](mailto:info@apicontext.com). ![Conformance Settings with the Manage Security Profiles dropdown open listing Basic, FAPI, FDX, and OAuth profiles](https://docs.apicontext.com/img/377aa42-image.webp) - Peruse all your conformance issues on the Issue Details page. Track where different issues are in your pipeline, choosing from Open, Acknowledged, Muted, and Resolved to organize your remediation plans. ![Conformance Issue Details page tracking unresolved issues by resource, check, and resolution status](https://docs.apicontext.com/img/3b396de-image.webp) - SLA & SLO settings have moved from the Performance page to the Conformance page for easier navigation. Find them now under Conformance Settings. ![Conformance Settings showing Service Level Objectives and performance change thresholds relocated from Performance](https://docs.apicontext.com/img/ebd4ebf-image.webp) ## Added: Uptime monitoring In addition to full synthetic monitoring, you can now create a simple uptime monitor for your APIs or your suppliers' APIs. These tests monitor for downtime, as frequently as once per minute, depending on your subscription level. If you want to learn more, reach out to our [sales team](mailto:info@apicontext.com). ## Added: Akamai agent locations New endpoints via Akamai Connected Cloud are now available in the Scheduling feature. ![Edit Schedule dialog with region toggles for continents and clouds including Akamai Connected Cloud](https://docs.apicontext.com/img/467ec91-Screenshot_2024-06-11_at_17.18.39.webp) A full list of all the new Akamai Connected Cloud endpoints is in [our node locations list](https://docs.apicontext.com/concepts/test-node-locations.md), with IP addresses to be added to your allowlists and locations to broaden the scope of your current APIs. ## Fixed: Conformance improvements - Better automatic OAS Specification uploading, tagging, and URL matching - Improved loading for the Conformance Issue Details and Conformance tabs - Updated permissions for Viewers for Conformance Issue Details - Fixed an issue with schema checks - New and updated Security Profiles are now available ## Fixed: Scheduling fixes - Fixed an issue where incidents were triggering during downtime - Updated agent lists to fix wrongly assigned agents - Fixed an issue where number of retries went over the user-defined limit ## Fixed: General improvements - Improved error messaging - Clearer messaging on pages when loading - Fixed an issue with user invites --- # Release Notes - 29th of March 2024 > Release notes for APImetrics, 29 March 2024: Governance renamed to Conformance with schema validation, a Level 0 security profile, and moved profile settings. Source: https://docs.apicontext.com/changelog/release-notes-29th-of-march This release revamps the Governance feature into Conformance with new schema validation capabilities, adds a beginner-friendly security profile, and reorganizes settings. ## Added: Conformance with schema validation We have revamped our **Governance** feature and changed it to **Conformance**. Now, your Security Profile checks will live here as well as our new Schema Validation tool. Upload as many of your OAS specs as you want via the [Inventory](https://docs.apicontext.com/guides/catalog.md) or via the Files section. APImetrics will check these specs against your implemented API calls and show you all your results in the **Conformance** feature. ![Conformance Summary page showing Security, Schema, Availability, and Performance pass and fail results](https://docs.apicontext.com/img/cc7e0b3-image.webp) If you want to learn more about this feature, see [our Conformance tutorial](https://docs.apicontext.com/guides/conformance.md). ## Added: Level 0 security profile A new Security Profile that checks for basic Authentication on each of your API calls. This is a great place to start if the Security Profiles we already provide are overwhelming and you need something more entry-level. To learn more, see [the Level 0 profile reference](https://docs.apicontext.com/concepts/security-profiles/basic-security-conformance-profile.md). ## Changed: Security profile settings moved With the shift to our **Conformance** feature, we have moved our Security Profile selector. It is now available in your Project Settings. From here you can choose from any of our available Security Profiles, which you can learn more about in [our Security Profiles guide](https://docs.apicontext.com/concepts/security-profiles.md). ![Project Settings page showing the relocated Security Profile selector](https://docs.apicontext.com/img/72e6492-Screenshot_2024-03-29_at_18.21.38.webp) ## Fixed: Bug fixes and improvements - The Darkspark webhook is now automatically added when using a Security Profile - Improvements to the FDX Security Profiles for better accuracy - Updates to Inventory to make the path and method of each API call clearer - Bug fix for calls to project-scoped APIs, Certification creation issues, and Results loading errors --- # Release Notes - 29th of February 2024 > Release notes for APImetrics, 29 February 2024: organization-level certificate management and new API calls for monthly project and slow-call reports. Source: https://docs.apicontext.com/changelog/release-notes-29th-of-february-2024 This release introduces organization-level certificate management and new API reporting endpoints. ## Added: Organization-level certificate management Upload MTLS certificates in Organization Settings and use them globally across your Organization rather than individually in each Project. All existing certificates will be migrated automatically. ![Organization Settings Configuration page for uploading certificates to use across all projects](https://docs.apicontext.com/img/8f57ed5-Screenshot_2024-02-27_at_12.04.48.webp) ## Added: New API reporting endpoints The APImetrics API has been updated with three new calls. For more information on how to use the APImetrics API, see [the Call object reference](https://docs.apimetrics.io/reference/call-object). **Report Monthly Project Data** `GET https://client.apimetrics.io/api/3/project/analytics/calls-monthly?start_date=<iso8601-date>` Include an `Apimetrics-Project-Id` header with your desired project ID. Returns: ```json { "meta": { "report_type": "project_monthly", "version": 1, "project_id": string, "month": iso8601-date-string, "created_at": iso8601-timestamp }, "data": [ { "day": iso8601-date-string, "test_id": string, "url": string, "pass_count": number, "slow_count": number, "warn_count": number, "fail_count": number, "total": number, "avg_server_time": number, "sum_server_time": number } ] } ``` **Report Slow Calls per Day** `GET https://client.apimetrics.io/api/3/organizations/{org_id}/analytics/slow-calls-daily?start_date=<iso8601-date>&end_date=<iso8601-date>` ```json { "meta": { "report_type": "slow_calls_daily", "version": 1, "start_date": iso8601-date-string, "end_date": iso8601-date-string, "created_at": iso8601-timestamp }, "data": [ { "day": iso8601-date-string, "project_id": string, "pass_count": number, "slow700_count": number, "slow800_count": number, "slow900_count": number, "slow1000_count": number, "slow2000_count": number, "warn_count": number, "fail_count": number, "total": number } ] } ``` **Report Slow Calls per Month** `GET https://client.apimetrics.io/api/3/organizations/{org_id}/analytics/slow-calls-monthly?start_date=<iso8601-date>` ```json { "meta": { "report_type": "slow_calls_monthly", "version": 1, "start_date": iso8601-date-string, "end_date": iso8601-date-string, "created_at": iso8601-timestamp }, "data": [ { "month": iso8601-date-string, "project_id": string, "test_id": string, "url": string, "pass_count": number, "slow700_count": number, "slow800_count": number, "slow900_count": number, "slow1000_count": number, "slow2000_count": number, "warn_count": number, "fail_count": number, "total": number } ] } ``` ## Fixed: Bug fixes and improvements - Improved load times in the UK and Azure agent downtime - Fixed an issue with access tokens not properly saving - Audit log now logs downtime events such as deletion and currently active status - Downtime period now starts even when schedule is unused - Downtimes now have locales set for timezones in winter, meaning DST is now respected --- # APIContext Changelog > Release notes and product updates for APIContext. Source: https://docs.apicontext.com/changelog Release notes and product updates for the APIContext platform. For service incidents and maintenance notices, see [Status](https://docs.apicontext.com/status.md). Subscribe via <a href="/changelog/rss.xml">RSS</a> to get notified of new releases. ## Recent releases