# Artist Profile By Name Resolver (`yungstentech/artist-profile-by-name`) Actor Resolve a free-text music artist, producer, songwriter, or band name to one Wikidata QID plus verified MusicBrainz, ISNI, IPI, Spotify, Discogs, and Apple Music IDs, ranked candidates, a computed confidence, and an honest no-match for names the public record does not cover. - **URL**: https://apify.com/yungstentech/artist-profile-by-name.md - **Developed by:** [Paul Mikulskis](https://apify.com/yungstentech) (community) - **Categories:** AI, Agents, Developer tools - **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: No ratings yet ## Pricing from $200.00 / 1,000 resolved profiles This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event ## What's an Apify Actor? Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Actors are written with capital "A". ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. The best way to integrate Actors is as follows. In JavaScript/TypeScript projects, use official [JavaScript/TypeScript client](https://docs.apify.com/api/client/js/docs.md): ```bash npm install apify-client ``` In Python projects, use official [Python client library](https://docs.apify.com/api/client/python/docs.md): ```bash pip install apify-client ``` In shell scripts, use [Apify CLI](https://docs.apify.com/cli/docs.md): ````bash # MacOS / Linux curl -fsSL https://apify.com/install-cli.sh | bash # Windows irm https://apify.com/install-cli.ps1 | iex ```bash In AI frameworks, you might use the [Apify MCP server](https://docs.apify.com/integrations/mcp.md). If your project is in a different language, use the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README Enter an artist or writer name, even a messy or ambiguous one, and get back a resolved identity record: a verified-or-null identifier bundle from Wikidata, a computed match confidence whose formula is published below, a ranked candidate list for common names, and cited enrichment (aliases, years active, genres, roles) as uncharged extras. It is built for music researchers, catalog-cleanup teams, and AI agents that need a normalized name-to-profile lookup before deeper catalog or rights work. ### What Artist Profile By Name Resolver does You give it a name. It searches Wikidata (CC0, keyless), scores every candidate with a deterministic, published formula, and returns the one it can defend or an honest ranked shortlist when the name is genuinely ambiguous. Every external identifier it returns comes from the selected entity's own Wikidata statements. The model never fills an identifier, so an ID is never borrowed from a same-name lookalike. The identifier bundle covers the join keys an agent actually chains on: MusicBrainz ID (P434), Wikidata QID, ISNI (P213), Spotify artist IDs (P1902), Discogs artist IDs (P1953), Apple Music artist IDs (P2850), and IPI (P1828) when Wikidata happens to carry it. Identifier fields are arrays, because a real entity can carry several valid IDs of one kind, and rank-ordered with the preferred value first. #### Worked examples (real input, real output) **Household name, high-confidence single match.** Input `{ "name": "Miley Cyrus" }` resolves to Q4235 with `match_confidence` 1.0 and a near-full bundle: MusicBrainz ID `7e9bd05a-117f-4cce-87bc-e011527a8b18`, three ISNIs, two Spotify artist IDs (`5YGY8feqx7naU7z4HrwZM6`, `14scxEoUN7Dcx1m4EQ7oHe`), a Discogs ID, and an Apple Music ID. IPI is null here, which is normal even for household names. **Niche name that raw search buries.** Input `{ "name": "Gigamesh" }` resolves to the music producer Q5560170. A raw Wikidata search ranks that entity third, below a 3D-mesh software framework and a Barcelona bookstore. The music-class gate demotes the non-music entities and surfaces the producer as the confident answer, with its MusicBrainz, Spotify, Discogs, Apple Music, and ISNI identifiers attached. **Ambiguous name, honest shortlist instead of a guess.** Input `{ "name": "Chris Brown" }` returns `outcome: shortlist`. Two music-class Chris Browns (Q155700, the American R&B singer, and Q115390006, a contemporary Christian artist) both score 1.0 inside the tie band, so no single profile is asserted and no identifier bundle is attached to either. The run bills `candidate-shortlist`. **Name with no music match, honest no-match.** Input `{ "name": "David Johnston" }` returns `outcome: no_match` with ranked same-name candidates, each marked "no music gate", and an honestly empty identifier bundle, because no David Johnston in Wikidata carries a music-class statement or a music identifier. This run is not charged a result event. You pay the request fee only. #### A public demo dataset you can open right now The examples above are not mockups. A three-row demo dataset, generated on 2026-07-10 by the current production build, is public and needs no Apify account: [Demo dataset: three rows, JSON](https://api.apify.com/v2/datasets/BDczWHlFMZccPn9Xf/items?clean=true&format=json) One row per sold result event: - Row 1, `{ "name": "Miley Cyrus" }`: `outcome: resolved`, confidence 1.0, the full identifier bundle shown above, cited enrichment fields. Bills `profile-resolved`. - Row 2, `{ "name": "Gigamesh" }`: `outcome: resolved` to the producer Q5560170, with his MusicBrainz, ISNI, Spotify, Discogs, and Apple Music IDs attached. Bills `profile-resolved`. - Row 3, `{ "name": "Chris Brown" }`: `outcome: shortlist`, both music-class Chris Browns ranked at confidence 1.0 inside the tie band, no identifier bundle attached to either. Bills `candidate-shortlist`. #### The same names through the free baselines, captured 2026-07-10 **Raw Wikidata search**, the free directory this actor reads: searching `Gigamesh` returns the music producer ranked third, below a 3D-mesh software framework and a Barcelona bookstore. Searching `David Johnston` returns ten same-name entities, none of them a music artist. The deterministic scorer and the music gate are the difference between that pile and the rows above. **A direct structured LLM web-search call** (Perplexity `sonar`, asked for `{"name", "spotify_artist_id", "musicbrainz_id"}` as JSON only, both calls made 2026-07-10): - Asked for `Chris Brown`: one artist back, no ambiguity signal, carrying the R&B singer's correct Spotify ID and a MusicBrainz ID that does not exist. The returned MBID `e319600a-9c0a-4b7b-9c0a-4b7b9c0a4b7b` returns 404 on musicbrainz.org and matches neither same-name artist's registered MBID. Wikidata lists two music-class Chris Browns (Q155700, the R&B singer, and Q115390006, a contemporary Christian artist); the single-answer reply collapses the two into one. - Asked for the contemporary Christian Chris Brown specifically: `"N/A"` for both IDs, plus explanatory prose appended to a reply requested as JSON only. That artist's Spotify ID (`03NN8FAKofZU6phsfHLKPw`) sits on his public Wikidata record. - This resolver on the same input, row 3 of the demo dataset: `outcome: shortlist`. Both Chris Browns score 1.0 inside the tie band, so no single profile is asserted and no identifier lands on the wrong namesake. An invented ID has no path into the output: every identifier field is copied from the selected entity's own Wikidata statements or left null. ### Pricing Billing is pay-per-event. There is a flat request fee on every validated run, and result events that bill only when they are produced. A no-match or an upstream failure pays the request fee only. | Event | Price | When it bills | |---|---|---| | `actor-start` | $0.02 | Every run that passes input validation, including no-match and upstream-failure runs. This is a request fee. | | `profile-resolved` | $0.20 | A confident single match with at least one verified identifier on the selected entity. | | `candidate-shortlist` | $0.18 | An ambiguous name that yields a ranked candidate list rather than one answer. | | `identity-core` | $0.05 | A confident Wikidata-only match with at least two verified identifiers, served on the no-model path (for example a free-tier caller). | Enrichment fields (aliases, years active, genres, roles, notable works, recent activity) are never charged. At most one result event bills per run. A confident match that carries zero external identifiers returns the profile and bills nothing beyond the request fee. **Trying it with no PPE event.** The default example in the Input tab (`{ "name": "Gigamesh", "dryRun": true }`) runs a real, bounded Wikidata lookup and charges no PPE event at all, not even the request fee, though ordinary Apify platform compute, storage, and egress usage still applies. `dryRun` only runs that exact sample; any other input with `dryRun: true` is rejected before any charge, lookup, or state read, and every other input runs the normal billed path described above. ### The confidence formula, published `match_confidence` is a deterministic score over the Wikidata data, not a model assertion. It is computed as a weighted sum and rounded to four decimals. - **With hints:** `S = 0.55 * N + 0.25 * M + 0.20 * H` - **Without hints:** `S = (0.55 * N + 0.25 * M) / 0.80`, which renormalizes the same two terms to the 0 to 1 range. **N, name match (weight 0.55)** is the highest tier reached across all of the candidate's labels and aliases after Unicode normalization, casefolding, and diacritic stripping: 1.00 for an exact match, 0.90 when the tokens match in any order, 0.75 when one token set contains the other (middle-name cases), a bounded value in the 0.51 to just-under-0.60 band for a close typo, otherwise 0. **M, music class (weight 0.25)** is binary: 1 when the candidate has a music occupation or musical-group class in a frozen, version-pinned set, or carries any of the MusicBrainz, Spotify, Discogs, or Apple Music identifiers, otherwise 0. **H, hint agreement (weight 0.20)** applies only when you supply hints. Each hint scores 1.0 when it agrees, 0.5 when the candidate is silent on it, and 0.0 when it contradicts. H is the mean over the supplied hints. **Decision rules.** The threshold is 0.60 and the tie band is 0.10. A leader is decisive only when its score is at least 0.60 and it clears the runner-up by at least 0.10. Precedence, refusal first: the music gate, then the tie rule (a tied top pair never becomes a single charged profile, even when the model agrees), then the threshold, then a hint veto, then model agreement, then the identifier floor. This ordering is why an ambiguous name returns a shortlist instead of a confident guess. ### Input - `name` (string, required): the artist or writer name. - `hints` (object, optional): `country`, `genre`, `role`, `knownWork`, `externalUrl`. Hints sharpen the score; they are never required. - `maxCandidates` (integer, optional, default 5, max 10): how many candidates are sent to the ranking model. The output row lists the full scored candidate pool. It never changes scoring or the tie test. - `includeSources` (boolean, optional, default true): include evidence URLs. - `dryRun` (boolean, optional, default false): charges no PPE event. Valid ONLY for the exact public Store preview sample (`name: "Gigamesh"`, no hints, `maxCandidates: 5`, `includeSources: true`); any other input with `dryRun: true` is rejected before any charge, lookup, or state read. The preview row is still written to your dataset and OUTPUT from a genuine, bounded, free, keyless Wikidata lookup, so ordinary Apify platform compute, storage, and egress usage still applies. ### Output One row per lookup. You can download the dataset in JSON, HTML, CSV, or Excel. Each field is provenance-typed with `value`, `source_type` (`wikidata` or `synthesized`), `source_urls`, `as_of`, and `confidence`. | Field | Meaning | |---|---| | `query_name` | The name you sent, echoed. | | `outcome` | `resolved`, `shortlist`, `identity_core_only`, `no_match`, or `error_upstream`. | | `best_match_name`, `match_confidence`, `ambiguity_level` | The selected entity, its computed score, and how ambiguous the name was. | | `identifiers` | `qid`, `mbid`, `isni`, `ipi`, `spotify_artist_ids`, `discogs_artist_ids`, `apple_music_artist_ids`. Each Wikidata-sourced or null, never model-filled, arrays ordered by statement rank. | | `aliases`, `years_active`, `genres`, `roles`, `notable_works`, `recent_activity` | Synthesized, cited, uncharged enrichment. A field with no allowlisted source is null. | | `ranked_candidates[]` | `name`, `qid`, `confidence`, `evidence_urls`, and a short reason per candidate. | | `warnings[]` | Budget, cache, and policy-drop notices. | ### Limitations - **Wikidata coverage is thinner for the long tail.** Many working songwriters have no Wikidata entity at all. When there is no entity, the run returns a no-match and is not charged a result event. The highest-value ambiguous queries are also the ones most likely to return an empty identifier bundle, and the ranked candidate list carries the value there. - **IPI is a rare bonus, not a headline.** IPI (P1828) is sparse in Wikidata even for household names, so it is returned when present and null otherwise. - **Identity resolution, not a rights registry.** This lookup resolves who an entity is and its stable join keys. It does not return per-track ownership shares. It composes with rights and catalog products that do. - **Enrichment is discovery-grade.** Aliases, years active, genres, and roles are synthesized with citations from a fixed allowlist of music press and public broadcasters. A fact with no allowlisted source is returned null rather than guessed. ### Composes with The join keys are made to be chained: - [Spotify Catalog Resolver](https://apify.com/yungstentech/spotify-catalog-resolver) turns ISRCs, UPCs, ISWCs, or free-text queries into full Spotify catalog metadata. Resolve the artist here first, and you know whose catalog you are looking at. - [MLC Rights Resolver](https://apify.com/yungstentech/mlc-works-resolver) resolves ISRCs or MLC song codes into the writers, publishers, and ownership shares The MLC has on file. That is the per-track rights layer this identity lookup deliberately does not duplicate. ### FAQ and support **Where do the identifiers come from?** Only from the matched entity's Wikidata statements. Wikidata is CC0, so the join keys are reusable without attribution. MusicBrainz is never called. **Why did I get a shortlist instead of one answer?** The name was ambiguous and the top candidates scored within the tie band, so the resolver returned ranked candidates rather than assert a single wrong one. **Why was I charged on a no-match?** The `$0.02` request fee applies to every validated run. Result events bill only when produced, so a no-match pays the request fee and nothing more. **Can I try it before paying?** Yes, with the default example input (`dryRun: true` on the exact `"Gigamesh"` sample). It charges no PPE event at all and runs a real, bounded Wikidata lookup, though ordinary Apify platform compute, storage, and egress usage still applies. `dryRun` is not a general no-charge mode: any other input with `dryRun: true` is rejected, and every other input runs the normal billed path. Feedback and bug reports go to the Issues tab. Custom fields or a wider enrichment allowlist can be scoped on request. SEO: artist profile, artist resolver, artist lookup, artist identity, MusicBrainz ID, ISNI lookup, Spotify artist ID, songwriter lookup, performer lookup, music metadata, MCP. # Actor input Schema ## `name` (type: `string`): The free-text music artist, producer, songwriter, or band name to resolve. Messy is fine: a stage name ("Gigamesh"), a legal name, or a band all work. The resolver anchors it to ONE Wikidata identity (QID) and returns its verified external music identifiers (MusicBrainz, ISNI, IPI, Spotify, Discogs, Apple Music). Acts with no Wikidata record, or names that are not music entities, return an honest no-match for the $0.02 run fee only. ## `hints` (type: `object`): Optional context to sharpen selection and enrichment. Fields (all optional, all checked against Wikidata statements): country (P27/P495, an English label or ISO alpha-2 like "US"), genre (P136), role (P106, e.g. "producer"), knownWork (P800, a notable work title), externalUrl (a Spotify / MusicBrainz / Discogs / Apple Music / Wikidata URL matched against the candidate's identifiers). ## `maxCandidates` (type: `integer`): How many candidates are sent to the ranking model. The output row lists the full scored candidate pool. Never changes scoring or the tie test. 1 to 10. ## `includeSources` (type: `boolean`): Include Wikidata evidence URLs on ranked candidates and citation URLs on the synthesized enrichment fields. Turn off for a leaner row without source links. ## `dryRun` (type: `boolean`): Charges no PPE event (ordinary Apify platform compute/storage/egress still applies). Valid ONLY for the exact default example above (name "Gigamesh", no hints, maxCandidates 5, includeSources true). Any other input with dryRun true is rejected before any charge, lookup, or state read. Leave this off to run your own real, billed lookup. ## Actor input object example ```json { "name": "Gigamesh", "hints": {}, "maxCandidates": 5, "includeSources": true, "dryRun": false } ```` # Actor output Schema ## `profiles` (type: `string`): No description ## `summary` (type: `string`): No description # API You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup. ## JavaScript example ```javascript import { ApifyClient } from 'apify-client'; // Initialize the ApifyClient with your Apify API token // Replace the '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = { "name": "Gigamesh", "hints": {} }; // Run the Actor and wait for it to finish const run = await client.actor("yungstentech/artist-profile-by-name").call(input); // Fetch and print Actor results from the run's dataset (if any) console.log('Results from dataset'); console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`); const { items } = await client.dataset(run.defaultDatasetId).listItems(); items.forEach((item) => { console.dir(item); }); // 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs ``` ## Python example ```python from apify_client import ApifyClient # Initialize the ApifyClient with your Apify API token # Replace '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = { "name": "Gigamesh", "hints": {}, } # Run the Actor and wait for it to finish run = client.actor("yungstentech/artist-profile-by-name").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print("💾 Check your data here: https://console.apify.com/storage/datasets/" + run["defaultDatasetId"]) for item in client.dataset(run["defaultDatasetId"]).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{ "name": "Gigamesh", "hints": {} }' | apify call yungstentech/artist-profile-by-name --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "command": "npx", "args": [ "mcp-remote", "https://mcp.apify.com/?tools=yungstentech/artist-profile-by-name", "--header", "Authorization: Bearer " ] } } } ``` ## OpenAPI specification ```json { "openapi": "3.0.1", "info": { "title": "Artist Profile By Name Resolver", "description": "Resolve a free-text music artist, producer, songwriter, or band name to one Wikidata QID plus verified MusicBrainz, ISNI, IPI, Spotify, Discogs, and Apple Music IDs, ranked candidates, a computed confidence, and an honest no-match for names the public record does not cover.", "version": "0.0", "x-build-id": "ss2Q7OPaQ8YEjd0Ms" }, "servers": [ { "url": "https://api.apify.com/v2" } ], "paths": { "/acts/yungstentech~artist-profile-by-name/run-sync-get-dataset-items": { "post": { "operationId": "run-sync-get-dataset-items-yungstentech-artist-profile-by-name", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for its completion, and returns Actor's dataset items in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } }, "/acts/yungstentech~artist-profile-by-name/runs": { "post": { "operationId": "runs-sync-yungstentech-artist-profile-by-name", "x-openai-isConsequential": false, "summary": "Executes an Actor and returns information about the initiated run in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/runsResponseSchema" } } } } } } }, "/acts/yungstentech~artist-profile-by-name/run-sync": { "post": { "operationId": "run-sync-yungstentech-artist-profile-by-name", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for completion, and returns the OUTPUT from Key-value store in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } } }, "components": { "schemas": { "inputSchema": { "type": "object", "required": [ "name" ], "properties": { "name": { "title": "Artist / writer / act name", "type": "string", "description": "The free-text music artist, producer, songwriter, or band name to resolve. Messy is fine: a stage name (\"Gigamesh\"), a legal name, or a band all work. The resolver anchors it to ONE Wikidata identity (QID) and returns its verified external music identifiers (MusicBrainz, ISNI, IPI, Spotify, Discogs, Apple Music). Acts with no Wikidata record, or names that are not music entities, return an honest no-match for the $0.02 run fee only." }, "hints": { "title": "Optional hints", "type": "object", "description": "Optional context to sharpen selection and enrichment. Fields (all optional, all checked against Wikidata statements): country (P27/P495, an English label or ISO alpha-2 like \"US\"), genre (P136), role (P106, e.g. \"producer\"), knownWork (P800, a notable work title), externalUrl (a Spotify / MusicBrainz / Discogs / Apple Music / Wikidata URL matched against the candidate's identifiers)." }, "maxCandidates": { "title": "Max candidates", "minimum": 1, "maximum": 10, "type": "integer", "description": "How many candidates are sent to the ranking model. The output row lists the full scored candidate pool. Never changes scoring or the tie test. 1 to 10.", "default": 5 }, "includeSources": { "title": "Include evidence URLs", "type": "boolean", "description": "Include Wikidata evidence URLs on ranked candidates and citation URLs on the synthesized enrichment fields. Turn off for a leaner row without source links.", "default": true }, "dryRun": { "title": "Dry run (public Store preview only)", "type": "boolean", "description": "Charges no PPE event (ordinary Apify platform compute/storage/egress still applies). Valid ONLY for the exact default example above (name \"Gigamesh\", no hints, maxCandidates 5, includeSources true). Any other input with dryRun true is rejected before any charge, lookup, or state read. Leave this off to run your own real, billed lookup.", "default": false } } }, "runsResponseSchema": { "type": "object", "properties": { "data": { "type": "object", "properties": { "id": { "type": "string" }, "actId": { "type": "string" }, "userId": { "type": "string" }, "startedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "finishedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "status": { "type": "string", "example": "READY" }, "meta": { "type": "object", "properties": { "origin": { "type": "string", "example": "API" }, "userAgent": { "type": "string" } } }, "stats": { "type": "object", "properties": { "inputBodyLen": { "type": "integer", "example": 2000 }, "rebootCount": { "type": "integer", "example": 0 }, "restartCount": { "type": "integer", "example": 0 }, "resurrectCount": { "type": "integer", "example": 0 }, "computeUnits": { "type": "integer", "example": 0 } } }, "options": { "type": "object", "properties": { "build": { "type": "string", "example": "latest" }, "timeoutSecs": { "type": "integer", "example": 300 }, "memoryMbytes": { "type": "integer", "example": 1024 }, "diskMbytes": { "type": "integer", "example": 2048 } } }, "buildId": { "type": "string" }, "defaultKeyValueStoreId": { "type": "string" }, "defaultDatasetId": { "type": "string" }, "defaultRequestQueueId": { "type": "string" }, "buildNumber": { "type": "string", "example": "1.0.0" }, "containerUrl": { "type": "string" }, "usage": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "integer", "example": 1 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } }, "usageTotalUsd": { "type": "number", "example": 0.00005 }, "usageUsd": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "number", "example": 0.00005 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } } } } } } } } } ```