GTmetrix

Delete a page tag via DELETE /page_tags/{tag_id}. PERMANENTLY DELETE one page tag and remove it from every page carrying it. There is no undo. The PAGES are untouched -- to take a tag off one page and keep the tag, use Detach tags from a page. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Delete a monitored page via DELETE /pages/{page_id}. PERMANENTLY DELETE one monitored page, its monitoring schedule, its alert conditions and its report history. There is no undo. Deleting a page is not the way to pause monitoring -- Set a page's monitoring frequency with `frequency: none` stops the schedule and keeps the page and its history. TWO 403s HERE ARE NOT CREDENTIAL PROBLEMS, and neither is fixed by pasting a new key. HTTP 403 code E40301 means the key's GTmetrix Team role is insufficient -- a Viewer-role key may not generate tests, delete reports or pages, or create PDF reports -- so the fix is a role change in the Team organization. HTTP 403 code E40300 means the account's e-mail address has never been validated; the fix is to validate it. Only HTTP 401 code E40100 means the key itself is wrong. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Delete a page's alert conditions via DELETE /pages/{page_id}/performance_alert_conditions. Remove EVERY performance alert condition from one page, so it stops raising alerts. There is no undo: the thresholds are gone and would have to be sent again. The page, its monitoring schedule and its alert history are untouched. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Delete a report via DELETE /reports/{report_id}. PERMANENTLY DELETE one report and every resource attached to it. There is no undo and no recycle bin: the report's own address and the collection it appeared in both stop naming it. The test that produced it is unaffected, and the credits it spent are not returned. TWO 403s HERE ARE NOT CREDENTIAL PROBLEMS, and neither is fixed by pasting a new key. HTTP 403 code E40301 means the key's GTmetrix Team role is insufficient -- a Viewer-role key may not generate tests, delete reports or pages, or create PDF reports -- so the fix is a role change in the Team organization. HTTP 403 code E40300 means the account's e-mail address has never been validated; the fix is to validate it. Only HTTP 401 code E40100 means the key itself is wrong. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List browsers via GET /browsers. List the browsers available to this account, each with the id that `browser` takes on Start a test, its name and version, its platform, and which features (video, ad-blocking, device simulation) it supports. A reference read with no parameters. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a browser via GET /browsers/{browser_id}. Read one browser by its id: its name, version, platform and the analysis features it supports. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List test locations via GET /locations. List the test locations available to this account, each with the id that `location` takes on Start a test, its name and country, the browsers it supports and whether it is a PRO-only location. A reference read: no parameters, and GTmetrix's credit table meters tests only, so this is documented as costing nothing. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a test location via GET /locations/{location_id}. Read one test location by its id: its name, country, supported browsers and whether it requires a PRO plan. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List page tags via GET /page_tags. List every page tag in this account, with each tag's id, name, description and background colour. Tag ids are what `filter[page_tag]` on List monitored pages and the attach/detach tools take. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a page tag via GET /page_tags/{tag_id}. Read one page tag by its id: its name, description and background colour. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List monitored pages via GET /pages. List the pages in this account's GTmetrix dashboard: the URL each one watches, the location and browser it is tested from, its monitoring frequency and its latest report. Paginated with `page[size]` (max 500) and `page[number]`, sortable on `page_id`, `created` and `latest_report_time`, and filterable on location, browser, tag, monitoring frequency, URL and the two timestamps. `filter[page_tag]` takes tag ids and, by default, matches pages carrying ALL of them; `filter[:bool]=OR` matches any. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a monitored page via GET /pages/{page_id}. Read one monitored page by its id: the URL it watches, its test location, browser and analysis options, its monitoring frequency, its tags and its latest report. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a page's latest report via GET /pages/{page_id}/latest-report. Read the most recent report for one monitored page in a single call, with the same shape Get a report returns. This is the one-call answer to 'how is this page doing now', with no listing and no sorting. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a page's alert conditions via GET /pages/{page_id}/performance_alert_conditions. Read the performance alert conditions configured on one page: each metric, comparison operator and threshold, whether a video is recorded when an alert fires (PRO only), and the recipients notified (Team organizations only). Read this before changing anything -- setting conditions replaces the whole list. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List a page's alert events via GET /pages/{page_id}/performance_alert_events. List the performance alerts one page has raised: when each triggered, which condition it was and the report that breached it. Paginated with `page[size]` and `page[number]`. This is the history; the thresholds themselves are read with Get a page's performance alert conditions. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List a page's reports via GET /pages/{page_id}/reports. List the report history of one monitored page -- the series behind a performance trend. Paginated with `page[size]` (max 500) and `page[number]`, sortable on any score, timestamp or metric (prefix with `-` to reverse), and filterable on every one of them with the five comparison operators (`:eq`, `:gt`, `:gte`, `:lt`, `:lte`) -- which is what makes 'reports since Monday whose largest contentful paint exceeded 2500 ms' one call. `filter[:bool]` decides whether several filters are ANDed (the default) or ORed. Time-valued filters take Unix epoch seconds and metric-valued filters take the units the report reports (milliseconds for times, bytes for sizes). GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a report via GET /reports/{report_id}. Read one finished report by its id: the GTmetrix grade and the performance, structure, PageSpeed and YSlow scores, and the full metric set -- TTFB, redirect, connect and backend time, first and largest contentful paint, time to interactive, total blocking time, cumulative layout shift, speed index, onload and fully-loaded time, page size and request count. It also links the report's own resources (the Lighthouse audit, the HAR, the filmstrip data and the resource summary), which have a tool each. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a named report resource via GET /reports/{report_id}/resources/{resource_name}. Read one of a report's remaining JSON resources by name. This integration accepts exactly three: `analysis-options` (the options the test was run with), `pagespeed.json` and `yslow.json` (the legacy PageSpeed and YSlow audits, present only on reports produced with `report: legacy` or `lighthouse,legacy`). The two TAR ARCHIVES GTmetrix also serves here -- `pagespeed-files.tar` and `optimized-images.tar` -- and the four binary resources (`screenshot.jpg`, `filmstrip-frame.jpg`, `report.pdf`, `video.mp4`) are REFUSED by name: they are unbounded bytes and this integration holds no artifact transport contract for them. The four JSON resources with a tool of their own (`lighthouse.json`, `net.har`, `filmstrip.json`, `resource-summary.json`) are read with those tools. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a report's filmstrip data via GET /reports/{report_id}/resources/filmstrip.json. Read the load filmstrip for one report AS DATA: one entry per captured frame with its timestamp. `base64=1` asks GTmetrix to inline each frame's image as base64 inside the JSON instead of linking it. The individual frame IMAGES (`filmstrip-frame.jpg`) are not available through this integration: they are raw bytes with no bounded artifact transport contract. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a report's Lighthouse audit via GET /reports/{report_id}/resources/lighthouse.json. Read the complete Lighthouse audit JSON for one report: every audit, its score, its weight in each category, and the opportunities and diagnostics with their estimated savings. `pretty=1` asks for it indented. Only reports produced with `report: lighthouse` or `lighthouse,legacy` have one. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a report's network HAR via GET /reports/{report_id}/resources/net.har. Read one report's full HTTP Archive (HAR): every request the page made, with timings, sizes, headers and status codes. This is the largest JSON resource a report has, and `pretty=1` asks for it indented. Do not pass `download=1` through this integration -- it asks GTmetrix to serve the document as a file attachment, and this connector follows no redirects and returns JSON. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a report's resource summary via GET /reports/{report_id}/resources/resource-summary.json. Read one report's page-composition summary: the number of requests and the transferred and uncompressed bytes, broken down by resource type (HTML, CSS, JavaScript, images, fonts, other) and by first versus third party. The cheapest way to answer 'what is making this page heavy'. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List simulated devices via GET /simulated-devices. List the device presets `simulate_device` accepts on Start a test, each with its id, name and the screen resolution, user agent and device pixel ratio it applies. A preset OVERRIDES `browser_width`, `browser_height`, `browser_dppx` and `user_agent`. A reference read with no parameters. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a simulated device via GET /simulated-devices/{simulated_device_id}. Read one simulated device preset by its id: the screen resolution, user agent and device pixel ratio it applies to a test. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get API status and credit balance via GET /status. Read this connection's GTmetrix account status: the remaining `api_credits`, when the balance next refills (`api_refill`) and by how much (`api_refill_amount`), the plan type, the Team role this key acts with, and whether the plan has PRO analysis options, PRO locations and white-label PDF access. This is the free call that answers both 'is this key still working' and 'can this account afford another test', so run it before starting a test rather than discovering an empty balance from a failure. ONE FIELD IS REDACTED. GTmetrix's JSON:API identity for the `user` resource IS the API key -- the vendor's own schema types this reply's `data.id` as the API key -- so returning it verbatim would put a live credential into a tool result, an audit event and a model's context. This integration replaces that single field with a sentence saying where to read the key instead. Every other attribute is returned untouched, which is what a credit and entitlement check actually needs. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

List tests via GET /tests. List the tests this account has started, newest first, with each test's state (`queued`, `started`, `completed`, `error`), the location and browser it ran on and -- once finished -- a link to its report. Paginated with `page[size]` (max 500) and `page[number]`, sortable on `created`, `started` and `finished` (prefix an attribute with `-` to reverse), and filterable on source, state, location, browser and the three timestamps. `filter[:bool]` decides whether several filters are ANDed (the default) or ORed. This reads the queue; it does not start anything and costs no credits. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Get a test via GET /tests/{test_id}. Read one test by the id `Start a test` returned: its `state`, the time it was created, started and finished, and -- once `state` is `completed` -- the report it produced. This is the poll a caller runs after starting a test. A test that ended in `error` carries the reason, which is a page-under-test problem rather than an API one. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Create or update a page tag via POST /page_tags. Create a page tag from `data.attributes` -- `name` is required and unique per account (45 characters maximum), with an optional `description` shown as a tooltip and a `color` as a six-character hex value with NO leading `#`. This one route does double duty: sending `data.id` UPDATES the existing tag with that id instead of creating a new one, which is the vendor's own design. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Update a page tag via POST /page_tags/{tag_id}. Update one existing page tag by its id. Only the attributes you send are changed and the rest keep their current values, so this is a partial update despite being a POST. `name` stays unique per account and `color` is a six-character hex value with no leading `#`. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Attach a tag to pages via POST /page_tags/{tag_id}/attach. Attach one tag to many pages at once. `page_ids` takes between 1 and 500 distinct page ids. This is the mirror of Attach tags to a page: one tag, many pages, rather than one page, many tags. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Detach a tag from pages via POST /page_tags/{tag_id}/detach. Remove one tag from many pages at once. `page_ids` takes between 1 and 500 distinct page ids. The tag itself survives. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Attach tags to a page via POST /pages/{page_id}/attach_tags. Attach one or more existing page tags to one page. `page_tags` takes between 1 and 500 tag ids and each id must be distinct. Tags already on the page are left as they are; nothing is removed. Create a tag first with Create or update a page tag. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Detach tags from a page via POST /pages/{page_id}/detach_tags. Remove one or more page tags from one page. `page_tags` takes between 1 and 500 distinct tag ids. The TAGS themselves survive -- only the association with this page is removed; Delete a page tag deletes the tag. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Set a page's alert conditions via POST /pages/{page_id}/performance_alert_conditions. Set the performance alert conditions on one page. Each condition names a `metric` (a score, a timing or a size), an `operator` (`<`, `=`, `>`) and a `value` in the units the Report API reports that metric in -- milliseconds for timings, bytes for sizes -- and at most ten conditions may exist. `create_video` keeps a video of the load that triggered an alert (PRO only); `send_to` names the Team organization members to notify by e-mail, and is required for Team organizations and unavailable otherwise. THIS REPLACES THE WHOLE LIST rather than adding to it: the `conditions` array you send becomes the page's complete set of alert conditions, and an EMPTY array removes every one of them. Read the current list with Get a page's performance alert conditions first and send it back with your change applied. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Set a page's monitoring frequency via POST /pages/{page_id}/performance_monitor. Turn scheduled monitoring on or off for one page and choose how often it runs. `data.attributes.frequency` takes `none` (or its alias `no`) to disable monitoring, or `hourly`, `daily`, `weekly` or `monthly` to enable it at that interval -- so a value read from a page's own `monitored` attribute can be sent back unchanged. Each scheduled run is a test and spends this account's credits when it fires, which is worth knowing before setting `hourly` on a free account with five trial credits. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Retest a monitored page via POST /pages/{page_id}/retest. Test one monitored page NOW, outside its monitoring schedule, with the options that page is configured with. The reply is a test resource with `state: queued`, so poll Get a test as after Start a test. The page's schedule is unchanged. SPENDS API CREDITS. GTmetrix's published prices: a Lighthouse report costs 1 credit, a PageSpeed/YSlow (legacy) report 0.7, both together 1.1, and a metrics-only report (`report: none`) 0.6; `video: 1` adds a further 0.9. A free/Basic account is given FIVE trial credits in total when its key is first generated, which is roughly four Lighthouse tests ever -- so treat every call to this tool as spending money. Read the remaining balance with Get API status and credit balance, which costs nothing. TWO 403s HERE ARE NOT CREDENTIAL PROBLEMS, and neither is fixed by pasting a new key. HTTP 403 code E40301 means the key's GTmetrix Team role is insufficient -- a Viewer-role key may not generate tests, delete reports or pages, or create PDF reports -- so the fix is a role change in the Team organization. HTTP 403 code E40300 means the account's e-mail address has never been validated; the fix is to validate it. Only HTTP 401 code E40100 means the key itself is wrong. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Retest a report via POST /reports/{report_id}/retest. Run the analysis that produced this report AGAIN, with the same URL, location, browser and analysis options, and get a NEW test back. The original report is left alone. The reply is a test resource with `state: queued`, so poll Get a test as after Start a test. SPENDS API CREDITS. GTmetrix's published prices: a Lighthouse report costs 1 credit, a PageSpeed/YSlow (legacy) report 0.7, both together 1.1, and a metrics-only report (`report: none`) 0.6; `video: 1` adds a further 0.9. A free/Basic account is given FIVE trial credits in total when its key is first generated, which is roughly four Lighthouse tests ever -- so treat every call to this tool as spending money. Read the remaining balance with Get API status and credit balance, which costs nothing. TWO 403s HERE ARE NOT CREDENTIAL PROBLEMS, and neither is fixed by pasting a new key. HTTP 403 code E40301 means the key's GTmetrix Team role is insufficient -- a Viewer-role key may not generate tests, delete reports or pages, or create PDF reports -- so the fix is a role change in the Team organization. HTTP 403 code E40300 means the account's e-mail address has never been validated; the fix is to validate it. Only HTTP 401 code E40100 means the key itself is wrong. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.

Start a test via POST /tests. Start a new GTmetrix analysis of a URL. `data.attributes.url` is the only required field; `report` chooses what is produced (`lighthouse`, `legacy` for PageSpeed/YSlow, `lighthouse,legacy` for both, `none` for metrics only), and `location`, `browser`, `browser_width`/`browser_height`, `simulate_device`, `throttle`, `adblock`, `cookies`, `user_agent`, `allow_url`/`block_url`, `video` and `retention` shape the run. The reply is the test resource with its id and `state: queued` -- an analysis is ASYNCHRONOUS, so poll Get a test with that id until it reports `completed` and then read the report it links to. `httpauth_username` and `httpauth_password` are HTTP access-authentication credentials for YOUR site, sent by GTmetrix's browser to the page under test; they are not GTmetrix credentials and have nothing to do with this connection's key. Reference values for `location`, `browser` and `simulate_device` come from List test locations, List browsers and List simulated devices, all free. SPENDS API CREDITS. GTmetrix's published prices: a Lighthouse report costs 1 credit, a PageSpeed/YSlow (legacy) report 0.7, both together 1.1, and a metrics-only report (`report: none`) 0.6; `video: 1` adds a further 0.9. A free/Basic account is given FIVE trial credits in total when its key is first generated, which is roughly four Lighthouse tests ever -- so treat every call to this tool as spending money. Read the remaining balance with Get API status and credit balance, which costs nothing. TWO 403s HERE ARE NOT CREDENTIAL PROBLEMS, and neither is fixed by pasting a new key. HTTP 403 code E40301 means the key's GTmetrix Team role is insufficient -- a Viewer-role key may not generate tests, delete reports or pages, or create PDF reports -- so the fix is a role change in the Team organization. HTTP 403 code E40300 means the account's e-mail address has never been validated; the fix is to validate it. Only HTTP 401 code E40100 means the key itself is wrong. GTmetrix rate-limits the API per account -- its own figures are 240 requests per 60-second window for GTmetrix Basic and 960 for most PRO plans -- and an exhausted window answers HTTP 429. That is a THROTTLE, never a bad key: wait for the window and retry rather than re-pasting the credential.