Blackfire API

Name: Blackfire API
Brand: Blackfire API
Availability: InStock

✓ Official Vendor SpecDeveloper ToolsMonitoring Observabilitybasic11 EndpointsREST

For Agents

Read Blackfire profiles, manage performance test builds, and inspect the environments and organizations being profiled. Useful for agents that gate deploys on performance assertions.

Install Jentic One Beta

Connect the Blackfire API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Blackfire API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Blackfire API.

Fetch a captured Blackfire profile by UUID for inspection or archiving

Create and retrieve Blackfire builds to gate CI on performance assertions

Pull the build report to see whether performance tests passed or regressed

GET STARTED

Start building with Blackfire API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Blackfire API for, with concrete tasks.

★ CI Gate on Performance Regressions

Wire a Blackfire build into a CI job to fail the pipeline when performance assertions regress. The integration calls POST /builds to create a build, runs the test scenario against the profiled application, then polls GET /builds/{uuid}/report for the assertion results. If the report flags regressions the CI step exits non-zero, blocking the merge until the underlying performance issue is fixed.

POST /builds with the target environment, wait for the build to complete, GET /builds/{uuid}/report and exit non-zero if any assertion failed.

Profile Triage Workflow

When a production performance issue is reported, an engineer or agent fetches the relevant Blackfire profile by UUID, inspects the captured trace, and posts a summary to the incident channel. GET /profiles/{uuid} returns the profile data and DELETE /profiles/{uuid} cleans it up after the issue is resolved. This shortcuts the manual click-through in the Blackfire UI.

Call GET /profiles/{uuid} for the supplied profile id, summarise the top three hotspots, and post the summary to a Slack channel.

Environment Configuration Audit

Use GET /environments and GET /environments/{uuid} to enumerate the Blackfire environments a team is monitoring, and PUT /environments/{uuid} to bring drifted settings back to a known baseline. This is useful when onboarding a new service or running a quarterly observability hygiene check across an organization's environments.

Call GET /environments, compare each environment's settings against the team baseline, and PUT updates to environments that have drifted.

Organization Access Review

Pull GET /organizations/{uuid}/members to review who has access to the Blackfire organization and cross-reference against the source-of-truth identity directory. Off-boarding workflows use the same endpoint to confirm that ex-employees no longer appear in the member list. This keeps performance-data access in line with broader access-management policy.

Call GET /organizations/{uuid}/members, diff the result against the HR active-employee list, and report any orphaned accounts.

Agent-Driven Performance Check via Jentic

An AI agent investigating a slow endpoint searches Jentic for a Blackfire build operation, kicks off a performance test, and reports the assertion outcome back to the engineer who triggered the request. Jentic stores the Blackfire Server ID and Token in its vault, so the agent never sees the raw HTTP basic credentials. This lets engineering chat-ops trigger profiling without copy-pasting secrets.

Use Jentic search for 'create a Blackfire build for a performance test', load the schema, then execute POST /builds and report the build report status when complete.

Key Endpoints

11 endpoints — the blackfire api is the programmatic surface for blackfire, a continuous observability and performance testing platform for php, python, go, and node.

METHOD

PATH

DESCRIPTION

GET

/profiles/{uuid}

Fetch a profile by UUID

POST

/builds

Create a performance test build

GET

/builds/{uuid}/report

Get the build assertion report

GET

/environments

List configured environments

PUT

/environments/{uuid}

Update an environment

GET

/organizations/{uuid}/members

List organization members

GET

/profiles/{uuid}

Fetch a profile by UUID

POST

/builds

Create a performance test build

GET

/builds/{uuid}/report

Get the build assertion report

GET

/environments

List configured environments

PUT

/environments/{uuid}

Update an environment

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Your Blackfire Server ID and Server Token are stored once, encrypted, by your own Jentic One instance, which builds the Basic header and injects it at execution time. They never enter the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'fetch a Blackfire profile' or 'create a Blackfire build', and Jentic returns the matching operation with its input schema and required path parameters so the agent calls the right endpoint without browsing the reference docs.

Time to first call

FAQs

Specific to using Blackfire API through Jentic.

What authentication does the Blackfire API use?

HTTP basic authentication. The Server ID is the username and the Server Token is the password (security scheme name BasicAuth in the spec). Through Jentic both values are stored in the encrypted vault and the agent receives a scoped token instead of the raw Server ID and Token.

Can I create a Blackfire build for a CI job with this API?

Yes. POST /builds creates a build, and GET /builds/{uuid}/report returns the assertion outcome. CI jobs use this pair to gate merges on performance regressions, polling the report endpoint until the build is complete.

How do I fetch a Blackfire profile?

Call GET /profiles/{uuid} with the profile id from the Blackfire UI or from a build report. The response contains the profile data; DELETE /profiles/{uuid} removes it when no longer needed.

What are the rate limits for the Blackfire API?

The OpenAPI spec does not declare a published rate limit. Treat the API as paced for CI and dashboard usage rather than high-volume polling, and back off on HTTP 429 responses if your CI fan-out grows.

How do I run a Blackfire performance check through Jentic?

Install with pip install jentic, then use Jentic search with 'create a Blackfire build for a performance test'. Load the POST /builds schema, execute it, then call GET /builds/{uuid}/report to retrieve the assertion outcome. Jentic resolves both calls without exposing the Server ID and Token.

Which languages does the Blackfire API cover?

Blackfire profiles PHP, Python, Go, and Node.js applications. The API itself is language-agnostic - the same endpoints (profiles, builds, environments) work for all four runtimes; the language-specific work happens in the Blackfire agent on the host.

Can I limit what my agent is allowed to do with the Blackfire API?

Yes. Because you run Jentic One yourself, you decide which Blackfire operations your agent may call, so read-only intents like GET /profiles/{uuid} or GET /builds/{uuid}/report can be allowed while a mutating call such as PUT /environments/{uuid} stays off unless you add it. Since Blackfire puts the resource uuid in the URL path, your own rules can pin the agent to a single profile or build so it reads that resource and nothing else. Your Server ID and Server Token are held by your instance and injected at execution time, so the agent never handles the raw credentials.