From what I see their API attempts to decouple two things that can not be decoupled; the creation and the signing of transactions (whether they are multisig or not).
I'm not even sure what benefit that is supposed to bring, but apparently they believe it is easier for developers to use a remote JSON API instead of a local bitcoin library[1] to generate transaction payloads.
The problem is that it is not trivial to inspect and verify the payload before signing it. It is an opaque hex-string. In order to verify that it contains what you want it to contain you need the same machinery that you'd use to create the transaction yourself in first place.
So if you choose to verify the transactions they make up for you before signing them then you could just as well generate the payload yourself.
If you don't verify the transactions they make up for you (which is what their documentation seems to expect) then you put your wallet at the mercy of whoever controls their servers. That is a very bad idea!
Meanwhile, creating and signing bitcoin transactions entirely in your own code, without talking to any remote party, isn't very hard to begin with.
Mature libraries and toolkits exist.
It is non-trivial to create and sign a transaction among multiple parties. The point of multisig is that you have several entities, some can be humans, some can be machines, programming languages can be widely different. And no matter what, signatures have to be assembled so someone has created some transaction for you to sign before and there has to be some correlation between the signatures of the different parties.
I've had in mind to add a section on how to verify the hex we return with a few simple rules. Following your feedback, we'll add that soon.
P.S. In case it wasn't clear already, I'm a co-founder and CTO at BlockCypher.
I'm not even sure what benefit that is supposed to bring, but apparently they believe it is easier for developers to use a remote JSON API instead of a local bitcoin library[1] to generate transaction payloads.
The problem is that it is not trivial to inspect and verify the payload before signing it. It is an opaque hex-string. In order to verify that it contains what you want it to contain you need the same machinery that you'd use to create the transaction yourself in first place.
So if you choose to verify the transactions they make up for you before signing them then you could just as well generate the payload yourself.
If you don't verify the transactions they make up for you (which is what their documentation seems to expect) then you put your wallet at the mercy of whoever controls their servers. That is a very bad idea!
Meanwhile, creating and signing bitcoin transactions entirely in your own code, without talking to any remote party, isn't very hard to begin with. Mature libraries and toolkits exist.
Here's how to create a multisig transaction using the sx toolkit: http://sx.dyne.org/multisig.html
[1] http://libbitcoin.dyne.org/