# Follow processing jobs in the developer console

The [developer console](/dashboard/developers) gives you a compact view of processing associated with your Twinbly account. Use it to find an integration's job, check its reported status, compare an estimate with a recorded processing cost, or collect useful details for support.

For example, after an application submits a capture, you can find the job by its ID and check the same account's recent activity without building your own reporting screen first. The console is also useful when you work in more than one Twinbly surface and need to identify where a job came from.

## Open the right account

Sign in with the Twinbly account connected to the work, then choose **Developer console** in the dashboard navigation or mobile account menu.

Processing API keys and scene access tokens serve different purposes. Processing keys create and run captures using the account's wallet. Scene access tokens read published content. The console links to [processing-key management](/dashboard/developers/keys), the [API guide](/developers) and account settings; opening the activity view does not start paid processing.

## Find a job

1. Open **Processing activity** and choose **Refresh** to request the latest records.
2. Search by job ID, status or input type.
3. Use **Source** to select All, API, Native or Web, according to the work you are looking for.
4. Read the job's source, input type, date and reported status. For an API job, its ID links to the corresponding library view where available.
5. Choose **Copy details** when you need to identify that job in a support conversation.

The view contains the latest 100 dated jobs associated with the account. Search and source filters work within those loaded records. This is recent job history, not a live request-by-request log or a complete lifetime activity statement. Refresh when you want an updated status.

## Read the two cost columns

**Estimate** is the processing estimate recorded for the job. **Recorded cost** is the processing cost reported for it. These are different from wallet charges and billing history.

**Not reported** means the value is unknown; it does not mean the job cost nothing. A displayed zero is a known zero. Do not add the visible rows together and treat the result as your account's total spend: the view has a history limit and some records lack cost data.

Use the console's **View billing history** link or [account settings](/dashboard/settings) to review billing. For integration reporting, the [API activity documentation](/developers#activity) describes credential-scoped reports, coverage and limits.

## When the job you expect is missing

- Clear the search and choose **All** sources, then refresh.
- Check that you signed into the account connected to the processing credential.
- Remember the 100-job limit. Older work can be outside this view.
- Partner-managed integrations can use a separate identity; their jobs are not automatically combined with your account's records. Undated older records are also outside the view.
- If activity cannot load, use **Retry activity**. An error is different from an empty job list.

A missing row is not a reason to submit the capture again. Reconcile the original job through the application or documented API before creating duplicate paid work. The console reports activity; it does not itself start, cancel or retry processing jobs.

## Share useful diagnostics

**Copy details** includes the job ID, source, status and input type. Add a short description of what you expected and what happened. Keep API key secrets, sign-in tokens and private upload or download links out of a support message.

For a problem in the web app itself, also copy the build information from About or [Product updates](/updates). The web build identifies the interface you used; the job ID identifies the processing work.

[Open the developer console](/dashboard/developers) · [Read the processing API guide](/developers) · [See the Legend Guide integration](/developers/legend-guide)