Day 0
Prove access
Create the key, complete one authenticated request, and save the first response with its metadata.
Open step →API workflow guide
What do you want to build?
Choose the outcome closest to your job. Each path gives you one working request, what the response should contain, how to check it worked, and the next useful step.
Five practical paths
Start with the outcome, not the endpoint list.
Selected: Harden a client
Path 1
Fetch macro data
Retrieve a clean time series and keep the source and quality metadata beside it.
Path 2
Plan release jobs
Use the release calendar to run targeted jobs around known publication times.
Path 3
Measure surprises
Join pre-release forecasts to the published value without introducing lookahead bias.
Path 4
Receive live updates
Use SSE as an invalidation signal, then fetch the complete record from REST.
Path 5
Build a macro model
Turn a small group of related indicators into a source-labelled currency scorecard.
Your 14-day API trial
Move from first request to a job worth keeping.
The goal is not to visit every product page. It is to complete useful authenticated API work, return on another day, and leave with a repeatable dataset or application workflow.
Days 1-2
Make the request dependable
Resolve authentication or filter problems and turn the first script into a named repeatable job.
Open step →Days 3-4
Add release timing
Use the calendar as a second endpoint family and schedule the next useful API run.
Open step →Days 5-7
Build the research output
Add expectations or a small group of macro series, then produce one saved comparison, table, or scorecard.
Open step →Days 8-10
Automate updates
Choose scheduled REST, SSE, or webhooks and complete another successful API run on a different day.
Open step →Days 11-13
Harden the client
Add timeouts, bounded retries, response validation, credential-safe logging, and stale-data monitoring.
Open step →Day 14
Review evidence
Confirm the API supplies a repeatable job your team will keep, then choose the next dataset or application workflow.
Open step →Production readiness
Make an API client production-ready
Production reliability comes from treating status codes differently, keeping retries bounded, reusing ETags, and choosing scheduled REST, SSE, or webhooks for the job.
Working example
Keep your key in FXMD_API_KEY; never paste it into source control.
import os
import requests
from urllib3.util.retry import Retry
session = requests.Session()
retry = Retry(total=3, backoff_factor=0.5, status_forcelist=(429, 502, 503, 504))
session.mount("https://", requests.adapters.HTTPAdapter(max_retries=retry))
response = session.get(
"https://api.fxmacrodata.com/v1/announcements/eur/inflation",
params={"api_key": os.environ["FXMD_API_KEY"], "limit": 5},
headers={"Accept-Encoding": "gzip"},
timeout=(3.05, 20),
)
response.raise_for_status()Expected result: A bounded client that handles transient failures without retry storms and is ready to add ETag-based conditional refreshes.
When the first script becomes a real system
Troubleshooting and production guidance
Use these guides when a response fails, returns no data, or needs production controls such as caching, timeouts, retries, and event delivery.
| Guide | Use it when | Start |
|---|---|---|
| Diagnose a failed or empty response | Separate authentication, access, path, rate-limit, and data-availability problems without exposing your key. | Open guide → |
| Make an API client production-ready | Add timeouts, bounded retries, caching, conditional requests, and the right delivery pattern. | Open guide → |