<feed xmlns='http://www.w3.org/2005/Atom'>
<title>typescript, branch main</title>
<subtitle>TypeScript/JavaScript client for the public CEP API
</subtitle>
<id>http://git.cep.is/typescript/atom?h=main</id>
<link rel='self' href='http://git.cep.is/typescript/atom?h=main'/>
<link rel='alternate' type='text/html' href='http://git.cep.is/typescript/'/>
<updated>2026-07-27T23:31:55Z</updated>
<entry>
<title>Carry the municipality of a CEP that does not exist</title>
<updated>2026-07-27T23:31:55Z</updated>
<author>
<name>Murilo Ijanc</name>
<email>murilo@ijanc.org</email>
</author>
<published>2026-07-27T23:31:55Z</published>
<link rel='alternate' type='text/html' href='http://git.cep.is/typescript/commit/?id=4ebb31f26efed74f8fcb049fe27ddf7cf5388a08'/>
<id>urn:sha1:4ebb31f26efed74f8fcb049fe27ddf7cf5388a08</id>
<content type='text'>
A CEP that fails is rarely a random number: it is someone who knows the
city and guessed the digits, and the classic guess is the -000 that 957
municipalities never received. The API now answers the 404 with the
municipality that band belongs to, which is enough to tell the user
"Areal/RJ, but not that number" instead of a bare failure.

It stays an error. Faixa hangs off CEPNotFound rather than becoming a
result, cep_ini/cep_fim are documented as the CEPs that exist there and
not as a range to iterate, and an absent or unreadable block yields
undefined so that context can never cost the caller the clean not-found
it was already getting.
</content>
</entry>
<entry>
<title>Initial import</title>
<updated>2026-07-26T15:15:55Z</updated>
<author>
<name>Murilo Ijanc</name>
<email>murilo@ijanc.org</email>
</author>
<published>2026-07-26T15:15:55Z</published>
<link rel='alternate' type='text/html' href='http://git.cep.is/typescript/commit/?id=986a16c34049187a6c1f39f38bfa59e327093494'/>
<id>urn:sha1:986a16c34049187a6c1f39f38bfa59e327093494</id>
<content type='text'>
</content>
</entry>
</feed>
