Address API error

[SkillzWhoKillz]

Hi again,

Thanks for all your hard work keeping this project alive. Big shoutout to you guys who keep it going, love your work

I believe the program is broken again.

Over the last few days I've been getting this error message address {"error":"address API returned status code: 401"}
When I try using the 500 Queen Street example in the Readme, it seems to be returning HTML for the webpage

I wish I could help more but I don't know what I'm doing. Would it be possible to give me some headers on how I can assist for any future errors?

Thanks

[rusq]

Thanks for the report. I reproduced this on 2026-05-21 with the current address endpoint:

GET https://experience.aucklandcouncil.govt.nz/nextapi/property?query=500%20Queen%20Street&pageSize=10

The response is 401 Unauthorized with:

{"error":"Authorisation error. Current IP address logged."}

I also checked the current Auckland Council collection-day frontend. It still calls /nextapi/property, but it now attaches Authorization: Bearer <session token> from a SessionTokenProvider. The existing aklapi request only sends browser-style headers, so the upstream API now rejects it before address matching happens.

Next step is to add a token acquisition/refresh path before calling /nextapi/property, or find a supported public address lookup endpoint that does not require the frontend session token. For future reports, the most useful details are: the address queried, endpoint used (/api/v1/addr, /api/v1/rr, or /api/v1/rrext), the exact JSON error body, and the approximate time the request failed.

[SkillzWhoKillz]

Hello,

Thanks for your prompt response and efforts!!! Almost missed my rubbish collection this week since the notification didn't work 😂

In the hopes of helping, with my limited homelabbing knowledge and ALOT of googling, I think I've figured out a few things.

Checking the network tab of Chrome Dev tools, I see that the webpage still pings
Request URL https://experience.aucklandcouncil.govt.nz/nextapi/property?query=500%20queen%20street&pageSize=10
so that hasn't changed like you mentioned.

I also see the new Authorization header you mentioned

Bearer eyJhbGciOiJIUzI1NiJ9.eyJzZXNzaW9uSWQiOiJhNmJmZTE2Mi0yY2NlLTRiOTgtOGVhMy01Mzc0OWQwMWI5MGMiLCJleHAiOjE3Nzk0NjM4MDN9.IDIhB1B-YpCE4y-r7y8WCL_niisbqDgpoFWSxm1dRrY

Since it starts with eyJ, its a JWT token(?) and decoding it revealed it has a TTL of 15 minutes. So that means we can't just hardcode it into the app.

I noticed that there isnt any call out in the network tab to an auth url anywhere. So I'm guessing that when you load up the webpage, the server issues you a session ID and a JWT token? I searched for my token and it comes up in the html for the webpage in the script section so its a JS server action and is loaded as soon as the webpage loads?

<script>
            self.__next_f.push([1, "5:[\"$\",\"$L19\",null,{\"initialToken\":\"eyJhbGciOiJIUzI1NiJ9.eyJzZXNzaW9uSWQiOiIzOD.....

So I'm guessing that if we curl the webpage and filter out this section of the HTML, we'd be able to get a auth token everytime?

I don't know what to do next or how to go about it but I hope that helps and I'm not just waffling 😂

[rusq]

Missing the collection is "not ideal", as one of my friends would say.

Thanks for reverse engineering effort, that's helpful. Yes, that's the general plan - get the initial token, then remember it at least for the duration of the session, or even cache it somewhere for its TTL — that would save 1 round trip per TTL :) ain't much but honest work.jpg

[rusq]

Status update from the Issue 32 fix work:

Implemented and verified the address API part of the fix.

What changed:

• Confirmed the current Auckland Council collection-day landing page embeds an initialToken in the Next/Flight payload.
• Added a small cached token provider that fetches that page at runtime, extracts the token, decodes JWT expiry when possible, and falls back to a short TTL otherwise.
• Wired address lookup requests to send Authorization: Bearer <runtime token>.
• Improved non-200 address API errors with bounded, sanitized upstream response snippets.

Verification:

go build -v ./...
go test ./...
PORT=18080 go run ./cmd/aklapi
curl 'http://localhost:18080/api/v1/addr?addr=500%20Queen%20Street'

Result for /api/v1/addr:

{"items":[{"id":"12342478585","address":"500 Queen Street, Auckland Central"}]}

Remaining limitation:

/api/v1/rr and /api/v1/rrext now get past address lookup, but the Auckland Council collection-detail page returns 406 for the selected address page. A real browser HAR of the same workflow shows the same thing: address search calls return 200, then the collection-detail request for the selected property returns 406. So the original address 401 is fixed, but rubbish collection detail is currently blocked by upstream behavior outside the token fix.

No captured bearer token, cookie, HAR payload, or private secret is included here or committed.

[rusq]

The only caveat that aucklandcouncil.govt.nz website and the rubbish page in particular returns 406 in my current location, so I'm only able to test the address API and it works. I submitted the PR #33 , — you asked if you could help, if that still stands — I'd really appreciate if you could you check it out and test it locally to confirm that the rest endpoints also work, because I can't ¯\_(ツ)_/¯ Once confirmed, I'll merge it. Thank you!