Refactor API layer into a centralized service and request management architecture

[Lakes41]

Difficulty: Advanced
Type: Refactor

Background

As GuildPass Mobile continues to expand, API interactions are becoming increasingly distributed across hooks, screens, and feature modules. Maintaining request consistency, error handling, retries, authentication refresh, and response transformation becomes progressively more difficult when networking logic is duplicated.

A centralized API architecture will improve maintainability and reduce technical debt.

Problem

Networking responsibilities are spread across multiple features, resulting in inconsistent request handling, duplicated logic, and reduced developer productivity when introducing new endpoints.

Expected outcome

Refactor the networking layer into a consistent service architecture with reusable request utilities, standardized error handling, authentication interception, and shared response parsing.

Suggested implementation

1. Audit all API requests throughout the application.
2. Create centralized service modules organized by feature.
3. Standardize request configuration, authentication, retries, and timeout behavior.
4. Introduce shared response and error transformation utilities.
5. Update feature modules to consume the new services.
6. Remove duplicated networking code.

Acceptance criteria

• All feature modules consume centralized API services.
• Authentication handling is standardized.
• Error handling behaves consistently throughout the application.
• Duplicate request logic has been removed.
• Existing application functionality continues working without regressions.

Likely affected files/directories

src/api/, src/services/, src/hooks/, src/features/, src/providers/

[mishellerv]

Hi! I’d like to work on this issue. I understand that the goal is to centralize the mobile application’s networking layer by auditing the existing API requests, creating reusable feature-based API services, and standardizing authentication, error handling, retries, timeouts, and response parsing. I’m interested in helping reduce duplicated networking logic while preserving the existing application behavior and avoiding regressions. I would appreciate the opportunity to work on this refactor and add the necessary changes to make API interactions more consistent across the application. If possible, I’d appreciate being assigned this issue. Thank you!

[grantfox-oss]

🦊 GrantFox — @mishellerv has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #218)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@mishellerv's PR #285 was approved and merged by @Lakes41.

🏆 @mishellerv: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

👏 Great work, @mishellerv! Keep contributing to Adamantine-guild.