Topic: [Announce] bitcoinmonitor.net - Free professional notification/payment service - page 6. (Read 19545 times)

I think I got an outline of a working system going for my bitcoin widget idea. Tomorrow is testing time and working out the bug. I hope the creator here will answer my question soon!

Or maybe other users can?

What happened when you input an address that is not valid? Is it possible for me to use the API to validate the bitcoin address somehow? Or is that not possible?

Thanks for doing this.

After having no idea how to do this thing ever, I finally figured out how to get a watcher created.

Hello, I have replicated the python example with ruby code.



Now, I  am trying to learn how to use your API so that I can do something interesting with it.

Well, I think you are right In the end it is probably better to deliver late notification instead of not at all. I will change the retry policy to retry up to one day, with an increasing time between tries.
Probably it also makes sense to have the maximum retry time a user-defined setting...

Indeed this would be better. But this will require some refactoring on my side. Might take some more time...

That's good to hear! And of course the API v1 is now stable and will not change anymore. So you are safe to rely on it 

Do you think there is anything lacking in the API? (Besides of the need of improved documentation I think...)

API works wonders - thanks so much! (Just don't change it now without incrementing the API version!)

API is now officially available!

There were only minor changes from the stuff i posted above:

• Authentication is now done via an API-key which you can obtain in your dashboard
• Resource URIs are now consistently in singular (e.g. ".../agent/..." instead of .../agents/...")

See the full documentation at http://www.bitcoinmonitor.net/apidoc/!

But what is a problem to increse retry time to for example 1 hour and try to deliver it for next 24 hours ? It would reduce a chance of lost money if site is offline.

Also you should make queue for sending so if you can not deliver 0 conf notification you should not try to deliver 6conf one.

Technically this would be possible. But overall i don't like the idea of storing notifications for such a long time. This whole notification concept is mostly about being quick. IMO it just does not make sense to deliver a notification days after it has happend.

Let's assume the common usecase of notifiying at 0 confirmations (for informing customer) and e.g. 6 confirmations for actually starting delivery of goods.
If the shop system would be offline for several hours there would be two notifications in the queue, each retrying every few minutes. If the shop comes online again it could happen that the notification for 6 confirmations comes in before the confirmation for 0 confirmations. This might not be handled well in the shop system.
On my side each notification is a completely independent event, so i can not define dependencies between different notifications (and i want to keep it that way for maximum modularity/scalability).

If you know your shop was offline for some time you can already now look up all failed notifications in the notification history (reminds me of the missing search/filter options there...).

An additional option would be adding a button to the dashboard to manually retry failed notifications. Maybe this would be a possible compromise?

Any chance for incrising POST retry times ?
Something like at least 24h would be great!

This is great for merchants who set deliberate time limits on orders because of fluctuations in exchange rate. You have 5 minutes to send the coins to the address, for example, or the order is canceled.

This is similar to the above in that the merchant is waiting for a set amount of coins before they mark the order as paid for in their system.

What I would really use is a combination, hybrid, if you will, of the above, where I set an amount and expiration time; if the address does not have in pending (unconfirmed) transactions within , the address is to be deleted. Let me know if this sounds unreasonable.
Edit: You should be able to define whether you'd like notifications on every incoming transaction, or only when the full amount is reached.

Quote from: Herbert on March 19, 2012, 06:42:38 AM

• any transaction is received ("one-shot")

I also can't find any good reasons for using this. Perhaps something like a lottery where the tickets are at least as divisible as bitcoins? You send any amount to the address, and get a lottery ticket equivalent to that amount of coins. Send as little as one satoshi, get one ticket.

Edit: Thank you for noticing and following up on this.

I am thinking about different possibilities here.

Remove watched address after

• a specified time without transaction ("time-based expiration")
• a specified amount is received/exceeded ("amount-based expiration")
• any transaction is received ("one-shot")

I think the first two variants make sense for different scenarios, while for the one-shot variant I can not think of a good usecase. Opinions?

Finished writing a zillion of unittests for the API and indeed found half a zillion bugs with them
=> Production site updated.

The API itself has not changed, so everything should work like before. Still I dont want to make the API "official" until a better authentication mechanism (probably oAuth) is in place.

Fixed

You missed the ID parameter, this should be:

(Also sent another bitcoin. I'm good to go now!)

Thanks mcorlett

3 new methods are now available for adding/listing/removing addresses of an agent. I edited my previous post to include the new methods (at bottom) :-)

Edit: Be prepared that the API will still change. You should not yet include it in production systems!

Sent the promised 0.5 BTC.

This is what I'm really looking for before I launch this service I'm working on. You've got another bitcoin in your wallet once you implement this!

Although I am not yet fully happy with it the API is now online  . I will certainly add some more stuff (oAuth authentication, better response/error messages, ...) but the general idea will stay like it is now.

The API follows the REST scheme, which means you can create, read, update and delete your agents and notification settings with standard http POST/GET/PUT/DELETE operations.

Currently only basic authentication is in place, so you have to provide user and password with each request, which of course is quite inconvinient... Next thing to add is oAuth token-based authentication.

Note: Be sure to always include the trailing slash in any url!

Get information about all your agents:
Browser: http://www.bitcoinmonitor.net/api/v1/agents/
Commandline using curl:

Create a new agent:
You need to provide only 2 parameters:

• name: The agents name
• watch_type: "1" for notification on withdrawal, "2" for notificatoin on deposits, "3" for both notifications
• addresses: (optional) list of addresses to watch, seperated by comma
  

Change an existing agent:
You need to know the ID of the agent (get it from the agent list). You can set:

• name: The agents name
• watch_type: "1" for notification on withdrawal, "2" for notificatoin on deposits, "3" for both notifications
• addresses: list of addresses to watch, seperated by comma
  

Delete an existing agent:
You need to know the ID of the agent (get it from the agent list).

Get notification settings for an agent:
You need to know the ID of the agent you want to work with (get it from the agent list). You need to provide the notification type you want to access:

• email
• url
• feed

Create new notification setting:
You need to know the ID of the agent you want to work with (get it from the agent list). Required parameters:

• req_confirmations: Confirmations required, 0 to 10
• email: email (required for type "email")

List bitcoinaddresses watched by agent:
You need to know the ID of the agent you want to work with (get it from the agent list)

Add a bitcoinaddress to an agent:
You need to provide 1 parameters:

• address: address to watch
  

Remove a bitcoinaddress from an agent:
No parameters as address is the ressource and part of url:


The agent_ID is guaranteed to never change once an agent is created. So if you have an agent set up it is safe to hardcode its ID in your code.

As all this is still not matured I will not add API documentation to the site itself. As soon as i got some user feedback and added the missing stuff I will also extend the documentation.