Your client has been rate-limited

Ah, learned something new today, thank you @kormoc . Individual and family accounts have the three free vault access credits available. Upgrades towards additional vault access credits (https://1password.com/products/secrets/#pricing) are available on the team and business plans.

1P_Simon: So I'm giving this a try, and when I try to assign vaults to the access token, it's throwing an error

You don’t have enough vault access credits to issue this token. Switch to 1Password Teams or Business to get more credits.
This action is not permitted.
ServerError: 403 (maximum_vault_access_credits)

@"Justin.Yoon_1P": I am on OS X, however I did notice I there's updates for the CLI. I am using the vault flag, but as I said, I was using a pretty high concurrency level, so perhaps that's why. I did lower the concurrency and so far haven't hit the same error.

@kormoc happy to let you know that Connect is also available on family and individual accounts. You can configure Connect via https://start.1password.com/signin?landing-page=%2Fintegrations%2Fconnect

You are right that it is not possible to share personal vaults. This is to ensure your personal vault remains private for you only. If in your case you want to share these items with the Connect service, you could move them in another vault to which both you personally as well as the Connect server have access.

If you run into any additional friction points, please let us know! We love learning about opportunities to improve your experience.

Hey @kormoc ,

I'm interested in why you are hitting a rate limiter even with the --cache flag enabled. Which platform are you on? If you are on Windows, the Windows client does not actually have a cache, and will hit the server to retrieve items every time.

Also, in your script, are you specifying the --vault flag when retrieving items? This can help reduce the number of API calls made on cache misses.

One other note, connect server doesn't work with family plans, just team/business plans. I'm not willing to pay an extra $3/user/month just to backup my secrets locally.

I believe Connect server doesn't have access to personal vaults, which leaves a hole in using it for any backup strategy. I've requested a feature to allow sharing of personal values in the past, and if that was implemented, connect server would be something to consider, but without the ability to have access to all my credentials, I don't feel it's a valid solution to the lack of local, offline backups

Hi folks, thanks for reaching out with this feature request! I'd love to understand a bit better your use case and requirements for disaster recovery.

Would hosting a 1Password Connect server in your own infrastructure, that has all your (encrypted) secrets backed up be a good solution for you? The 1Password Connect server will continue to operate even when 1Password.com cannot be reached and since you host in in your own infrastructure you are in full control over it.

Looking forward to learn more about your use case!

I have the same situation, I've created a script to create a local backup of our secrets and also the script walks every item.
I'm figuring out to add a wait command between each amount of exported secrets.

I was working on building a script that mirrors my 1Password data into a passwordstore local vault. This is for disaster recovery, as without local vaults, I no longer have a way to backup my data and be sure that it's available. I understand AgileBits position is that backups are not necessary, however I'm not willing to put all my eggs in a single basket that I don't control.

The script walks every vault, item, document, etc and diffs against the stored versions and updates them on modifications. I was running with 16 thread concurrency, which I presume is why I hit the rate limiter? I'll reduce the concurrency and see if that fixes the issue.

I am using the --cache argument with the cli commands.

Thank you.

Hey @kormoc!

Thank you for reaching out to us!
Currently, we do not document our rate-limits. However, they are set high enough to make sure that nobody would run into them through regular usage. Can you provide some more details about your use-case, and about what your tests try to achieve? Maybe we can find a way to get to your desired outcome without hitting the rate limits.

Looking forward to hearing from you!
Best,
Horia