Reliable Background Screening - Developer Portal Access Setup

Date: March 19, 2026

Participants: Alan Lasky, Rudi Troisi (Reliable), Larry Czerwonka, Devon (development team), Christopher Harer (Tazworks support)

Call Context: Technical coordination call to establish developer portal access for Chrome extension integration project. Larry and Devon needed API authentication credentials to begin development work on Reliable's background screening extension. Christopher (Tazworks) facilitated account setup and access provisioning. Duration approximately 20 minutes.

TASK COMMITMENTS BY PERSON

Christopher Harer (Tazworks):

• Approved Devon's developer portal access and assigned to Reliable Background Screening sandbox account (Timeline: completed during call)

(Christopher Harer): "I went ahead and approved Devon's access and then assigned him to the Reliable background screening sandbox account. So Devon, I know you said your microphones can't really talk, but if you go if you log in to the developer portal, you should now see the application."

• Will keep support case open for API questions and respond via email chain (Timeline: ongoing, case remains open)

(Christopher Harer): "I'm just gonna reply to that email chain, Devon. I think the last one you got was from Cameron. I'll keep the case open for a little bit. If you have any questions or anything like that, just respond to that email chain."

• Will increase API rate limit threshold if needed for development work (Timeline: as needed upon request)

(Christopher Harer): "Yeah. If you do feel like you're going to be hitting more requests like that, we do have the ability to increase that up into a certain point."

Larry Czerwonka & Devon:

• Will implement selective refresh strategy to stay within API rate limits — individual record refresh on user click rather than bulk data pulls (Timeline: design decision for development)

(Larry Czerwonka): "We'll just be more creative and make sure do we really need do we need up to date data right this second? And if the person does, then they click a little refresh just on that one entity that we want more data for, and then we shouldn't hit your limits."

Alan Lasky & Rudi Troisi (Reliable):

• Confirmed existing Reliable Background Screening sandbox account (Timeline: verified during call)

(Christopher Harer): "I do see a sandbox account for Reliable. Currently, it looks like Brett and Rudy, you're both registered for that."

KEY DISCUSSION POINTS

Account Ownership Best Practices

Larry emphasized importance of Reliable owning their own developer account rather than having development team create account under their company name. Prevents future access issues if development relationship changes.

(Larry Czerwonka): "My recommendation to Reliable is that they should set up that developer account just because then it's cleaner. Just because they're working with me today doesn't mean they're working with me a year from now."

Rationale:

Developer relationships can change over time
Client maintains continuous access regardless of vendor changes
Avoids "Larry had that account, how do I get there?" scenario
Multiple users can access same developer portal under client's account

(Rudi Troisi): "I totally agree with you. You make sense, Larry. Obviously, we're not looking to change, but things happen."

Existing Account Discovery

Christopher identified Reliable already has sandbox account with Brett and Rudi registered, plus five separate developer accounts for custom integrations built over the years (Realty ONE Group, EOS Production, Livette, Property Czar, TriWest).

(Christopher Harer): "I do see a sandbox account for Reliable. Currently, it looks like Brett and Rudy, you're both registered for that."

Resolution: Rather than creating new account, Christopher assigned Larry and Devon as additional users to existing Reliable sandbox account, maintaining clean ownership structure while giving development team necessary access.

API Rate Limiting Strategy

Larry proactively addressed API rate limit constraints by designing selective refresh architecture — system pulls individual records on user demand rather than bulk-updating all visible data automatically.

(Larry Czerwonka): "So instead of pulling all 40 people that they see on the screen, they pull the one that they really want."

Design Approach:

Default view shows cached/static data for all records
User clicks refresh button on specific record needing current data
Single API call retrieves only requested record, not entire dataset
Stays well within rate limits without requesting threshold increase
Improves performance by reducing unnecessary API calls

Developer Portal Multi-User Access

Christopher clarified developer portal supports multiple registered users accessing same account — doesn't require single login shared across team. Each developer registers individually and gets assigned to client's account.

(Christopher Harer): "You can have multiple users have access to the same When you create a developer portal, you know, we create the name, everything like that for you. And then you can have multiple emails register and have all those users have access to that developer portal."

Project Momentum

UNBLOCKED (8/10)

Access credentials established, development can proceed immediately