Hi everyone. I'm still pretty new to using Terraform and Fellow together for team management. I just set up a workflow to automatically pull team OKRs from Perdoo into our Fellow check-ins.
It involved using Perdoo's API and a bit of scripting. I was nervous about the security part, handling API keys safely outside of the script. Here's the core part where I fetch the objectives:
```python
import requests
def get_perdoo_okrs(api_key, team_id):
headers = {"Authorization": f"Bearer {api_key}"}
url = f"https://api.perdoo.com/v1/teams/{team_id}/objectives"
response = requests.get(url, headers=headers)
return response.json()
```
Has anyone else done something similar? I'm worried about the long-term cost if our team grows a lot. Also, wondering if I should manage the API key using AWS Secrets Manager with Terraform instead of my current method. Any tips to make this more robust?
AWS Secrets Manager with Terraform is a solid move for the API key. We've done that for our CI/CD tooling. The IAM integration is cleaner than hardcoding.
Watch your API rate limits when the team grows. Perdoo's pricing tiers can get expensive fast if you're hitting endpoints constantly. Consider caching the OKR data instead of fetching for every check-in.
We run something similar, but we pipe it through a Lambda on a schedule. That way, you're not paying per-call from Fellow's side. Terraform can manage the whole stack, Lambda included.
Your Python snippet is fine for a start. Just make sure you're handling pagination in the response. Perdoo's API often paginates large lists of objectives.
Benchmarks or bust.
That's a great start! I've used Perdoo's API quite a bit, and you're right to be thinking about key security early.
For the cost question, user604 is spot-on about caching. We schedule a nightly sync to pull all active OKRs into a simple database table, then our check-in workflows read from that. It saves a ton on API calls and is way faster for the end user.
Using AWS Secrets Manager with Terraform is definitely the way to go. It keeps your key out of version control and makes rotating it much simpler. One caveat: make sure your Lambda's IAM role (or whatever runtime you use) has the absolute minimum permissions needed to fetch that one secret. It's easy to get over-permissive there.
Did Perdoo's API give you any trouble with nested key results? Sometimes the structure changes slightly between their quarters.
Data-driven decisions.
Totally agree on the IAM caution. We learned that the hard way when a Lambda got too much access during a rushed deploy. The principle of least privilege is key, especially with secrets.
On the structure changes, we've seen that too! We ended up adding a simple schema check in our nightly sync script. If the response structure doesn't match our expected keys, it sends an alert and uses the cached data from the previous day. It's saved us a few times when Perdoo rolled out API updates.
Caching in a database table is brilliant for speed, we just use a cheap DynamoDB setup. Makes the Fellow check-in populating almost instant, which the team loves. Have you had to deal with historical OKR data for reporting, or just active ones?
Benchmark or bust
That Python snippet is a solid foundation, but you'll quickly hit scaling walls without pagination. Perdoo's API defaults to, what, 20 items per page? Your function will only grab the first page of objectives for that team. You need to loop until `next` is null in the response links. Something like this pattern:
```python
okrs = []
while url:
response = requests.get(url, headers=headers)
data = response.json()
okrs.extend(data.get('objectives', []))
url = data.get('links', {}).get('next')
```
On cost, I think you're right to be concerned. The real expense isn't just API calls, it's the coupling; if your Fellow check-in process calls this live, latency and Perdoo's availability become your problem. The move to a scheduled cache, as others noted, decouples that and makes cost predictable. Using Terraform to provision the secret store is absolutely the correct next step for the key - it makes rotation a non-event.
API whisperer
Love the Lambda-on-a-schedule idea for cost control. That's exactly the kind of shift that keeps things cheap at scale. I'd add one thing from a monitoring angle - make sure you've got a CloudWatch alarm on that Lambda's error metric. If your nightly sync fails silently because of an API change or a pagination bug, you might be serving stale OKRs for days before anyone notices. A simple alarm on `Errors > 0` for 1 datapoint has saved our setup a couple times.
And yeah, +1 on the IAM integration being cleaner. It feels more "terraformy" to manage the secret and the access policy in the same plan, rather than juggling keys in a separate vault.
cost first, then scale
That pagination loop is a lifesaver. We didn't catch that right away and spent a while wondering why our sync was missing objectives after a certain team size.
The point about coupling is so key. When we first built ours, the Fellow check-in would hang for 2-3 seconds while it waited for the Perdoo API. Moving to a cache made the user experience feel instant. Predictable cost was just a nice bonus.
Less hype, more data.
That schema check with fallback to cached data is clever. I've been burned by Perdoo's API adding fields mid-quarter without warning. We do something similar with a JSON schema validation in our GitOps pipeline, but we just flag it and block the merge instead of falling back. Might steal your approach for the prod path.
On historical data, we store everything in a time-series database (InfluxDB actually, running on a tiny k3s node). Lets us track OKR progression over quarters for the team retro. DynamoDB is nice for the instant reads though, we use it for the live Fellow queries too. How do you handle the TTL on old objectives? We just let DynamoDB delete them after a year, but I'm paranoid about losing data for the yearly review.
yaml all the things
Your approach is fundamentally sound, but the live API call in the check-in flow introduces a hard performance and availability dependency. The cost concern is valid and scales linearly with team growth if you call Perdoo directly each time.
Managing the API key with AWS Secrets Manager via Terraform is the correct security posture. However, that's only one layer. The more critical architectural shift is to move from a direct integration to a scheduled, cached synchronization. This decouples your system's read latency from Perdoo's API performance and eliminates per-check-in API costs. Implement a Lambda on a CloudWatch Events schedule that uses the secret to pull all objectives, handling pagination as noted by user924, and writes them to a cheap, fast datastore like DynamoDB. Your Fellow workflow then reads from this cache.
For robustness, your Lambda must include three things beyond the fetch logic: structured logging of record counts to confirm completeness, a dead-letter queue to capture failed invocations for analysis, and idempotent writes to your cache to handle potential duplicate Lambda executions. This turns a fragile point-to-point script into a resilient, monitorable data pipeline.
Scheduled Lambda is fine until you need near-real-time updates. Sometimes teams update OKRs midday and you want that reflected.
IAM integration is neat, but have you timed how long it takes to roll a secret in Terraform? In a fire drill, I'll take a plain env var any day.
And pagination? That's the absolute bare minimum.
>until you need near-real-time updates
This is the classic over-engineering trap. Let's be honest, how many OKRs are being revised with such urgency that a few hours of lag in a Fellow check-in causes a crisis? If your team's strategy is that volatile, you've got bigger problems than sync cadence.
As for the "plain env var in a fire drill," you've just described the exact scenario where I'd want IAM and Secrets Manager. When you're panicking, the last thing you need is a manual, error-prone key rotation across ten different services. Terraform might take a few minutes to roll, but at least it's consistent and logged. Your "quick" env var change is the one that gets forgotten in three repos and causes the next incident.
And yes, pagination is the bare minimum. Which is precisely why so many of these integrations skip it.